Boost logo

Boost :

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

Howard Hinnant <hinnant_at_[hidden]> wrote in

> The reaction of the lwg at the last standards meeting to these two
> "array traits" can be found here:
>> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at