Re: [boost] Discovering array size

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2003-12-03 12:47:23

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.

> I've seen the mental mess built-in arrays cause for students:
> "You mean, everything passed by value makes a copy, but arrays passed 
> by
> value is a reference? What do you mean it 'degrades' to a pointer---it
> looks like an array!"

<chuckle>  Yeah, got that t-shirt. :-)

>  Not to mention the inability to add bounds checking,
> which any TR1 implementation could trivially add in debug mode and 
> save us
> lowly TAs lots of time when helping students debug...

Yup, I like std::tr1::array too.

> So basically... I'd rather not add anything that encourages people to 
> use
> built-in arrays, especially now that we've given them a better option.

> Doug the Array-hater

<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 recommend that we keep these utilities.  We have pointer (and array) 
types in the language and that's not going to change.  I think it is 
better to embrace and support these parts of the language rather than 
neglect them.  Yes, a smart pointer is almost always better than a 
built-in pointer.  And yes, a smart array is almost always better than 
a built-in array.  But sooner or later someone is going to really need 
to deal with these built-in types (often for legacy reasons).  It might 
as well be easier and less error prone rather than harder and more 
error prone when they do.

<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.

-Howard