|
Boost : |
From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-05-31 19:18:38
----- Original Message -----
From: "AlisdairM" <alisdair.meredith_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, May 31, 2005 7:52 PM
Subject: [boost] Re: Boost Array Initialization Technique
> christopher diggins wrote:
>
>> This is much more flexible and it allows us to have constructors in
>> boost::array thus making it a full reversible container.
>
> boost::array can never be a standard conforming container because it
> does not support insertion/removal of elements - it is a fixed size.
I believe the standard only requires insertion/removal of elements on
sequences but not containers.
> When array was first proposed for TR1 we made suggestions to revise the
> container concepts to support both 'fixed size' and 'dynamic'
> containers. The consensus was that this was too much fiddling just to
> make array into a container. Instead, it was accepted as-is, as a
> 'container-like' class template.
My points are that an alternative approach which would require less fiddling
with the standard would have been to have uninitialized arrays have a size()
of zero. Despite being not "array-like" it would help reduce the possibility
of bugs. Furthermore as I pointed out in my previous post being
"container-like" does more harm than good, because it simply can not be used
safely where a container is expected, and leaves the dangerous illusion that
it can. As a result, mixed messages will be sent to the programmers. I can
just imagine the chaos that is going to erupt on the newsgroups if this gets
into the standard as is:
Newbie: array causes my existing code base for dealing with containers to
break.
Guru: array isn't a container
Newbie: but it looks just like a container
Guru: yes, it is container-like
Newbie: what does that mean?
Guru: it means that it looks like a container, but it shouldn't be used as a
container
Newbie: why was that done?
Guru: *shrugs*
> Aggregate initialization is an important part of the array concept,
I think precisely ust how important is debateable.
> allowing it to act largely as a plug-in replacement for language
> arrays, with the bonus it can be passed by value as well as by
> reference. The main drawback here is that we cannot deduce the size of
> a boost::array, as you can with a language array.
Christopher Diggins
http://www.cdiggins.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk