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
> 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
> 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
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
So should we remove:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk