[boost] Re: Discovering array size

From: AlisdairM (alisdair.meredith_at_[hidden])
Date: 2003-12-03 10:29:07

Howard Hinnant <hinnant_at_[hidden]> wrote in
news:488ABE03-259E-11D8-9373-003065D18932_at_[hidden]: 

> The reaction of the lwg at the last standards meeting to these two 
> "array traits" can be found here:
> 
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1541.pdf
> 
>> The LWG wasn’t sure whether this was useful; 
>> the few people who could use it reliably for metaprogramming would
>> probably find it just as easy to write it themselves.
> 
> I disagree with this stance and it is on my to-do list to motivate 
> dimension and rank for the Spring meeting.  As you appear to have a 
> need for at least "dimension", I would appreciate it if you could 
> expound on your desire for this functionality.  Any arguments you
> might have for why this functionality belongs in the
> std::tr1::type_traits lib will be incorporated into my own comments
> and presented to the lwg. 

Well, I'm trying to use dimension in a non-metaprogramming use-case <g>

We have quite a few places in our codebase where we allow the compiler to 
determine array size for us:

sometype var[] = { initialiser-list };

Often we need to pass this array to some function or library algorithm, and 
then we need the upper bound.  This is not readily available from var 
without resorting to

  sizeof(var) / sizeof(var[0]);

Much nicer to pick it out with 

  dimension( var );

So it's not something that can't be worked around, but going directly to 
the answer rather than seeing the calculation and worrying about whether 
packing / alignment is an issue etc. simplifies code reviews etc.

The problem here is obtaining the type of var.  Using a function template 
allows for type-deduction, but does not yield a compile time constant.

Personally, I would rather use tr1::array for this <g> but again we have no 
syntax to deduce array size here so must fall back on traditional C arrays.

AlisdairM