Re: [boost] Discovering array size

From: Douglas Paul Gregor (gregod_at_[hidden])
Date: 2003-12-03 13:42:05

On Wed, 3 Dec 2003, Howard Hinnant wrote:

> On Dec 3, 2003, at 10:27 AM, Douglas Paul Gregor wrote:
>
> > Arrays don't play nice with the standard library,
>
> Could you give an example or two on this?  I always thought that a
> strength of the std::lib was that it /did/ play nice with built-in
> arrays.  And I don't want to miss your point.

Well, arrays are just not _objects_ like all of the STL containers. They
don't have begin()/end() to get iterators, they don't have a size() member
function, or a value_type typedef, and can't be copied around like objects
can. The lib plays nice with arrays, but arrays don't want to join in the
fun.

It's just totally maddening that we have these wonderous consistencies
amongst vectors, lists, map, unordered_sets, etc., but this stupid little
array, the most trivial of all of the containers, has to stick out and be
different.

> <big laugh!>  Thanks Doug.  I can definitely see where you're coming
> from.
>
> Otoh, I've heard similar arguments about pointers.  One should never
> expose a pointer.  Smart pointers are so much better than built-in
> pointers.  Pointers are so dangerous many languages don't even have
> pointer types.
>
> So should we remove:
>
> is_pointer;
> remove_pointer;
> add_pointer;
>
> ?

I use lots of smart pointers, but there are many places where regular
pointers are still needed. Regular pointers, although they are often
considered dangerous, have pretty much the same syntax/semantics as smart
pointers. I don't think the same confusion factor applies to pointers.

We know we need to keep is_pointer, remove_pointer, and add_pointer.
We use them all the time in metaprogramming, and we can't get rid of them.
Even if I wanted to axe non-smart pointers I would still want to keep
those type traits.

> <shrug>  An array is a type.  Describing built-in types is type_trait's
> main gig. Shunning one type out of all the rest seems unnecessarily
> inconsistent.

I'm happy with keeping is_array (it's a very basic type trait, I think),
but rank and dimension haven't proven themselves. Do we even have them in
Boost? <looks it up> No, we don't, so one could conjecture that perhaps
they aren't necessary. remove_bounds is in the Boost type traits lib,
although it doesn't seem to be used anywhere in the library itself.

We better be darn sure we need rank and dimension before we reserve those
names in namespace std::tr1 or std.

        Doug