Boost logo

Boost :

From: Sohail Somani (s.somani_at_[hidden])
Date: 2006-07-20 13:03:43


But scoped_array is meant to be a C++ array.

Its only goal is (and probably should be) to call delete[].

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Steven Burns
> Sent: Thursday, July 20, 2006 9:22 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] boost::array support for runtime-sized arrays
>
> Actually the size of the container I have would be (sizeof(void*) +
> sizeof(size_t)) because you have to store the array's length,
> so I have to
> agree is starting to look like we are better of using std::vector.
>
> The problem I see with scoped_array is that it doesnt even
> have a size() or
> equivalent method which is kind of mandatory for very array class.
>
> Steven.
>
>
>
> "John Maddock" <john_at_[hidden]> wrote in message
> news:005e01c6ac13$0cd8f8e0$ea8c0252_at_fuji...
> > Steven Burns wrote:
> >> Indeed I did a partial spec. when the size is 0 (size_t
> cannot be -1)
> >> Losing the aggregate behavior was not an option so I only have
> >> constructors on this specialization.
> >>
> >> This means you can still do this:
> >>
> >> boost::array<int, 5> sarray = {1,2,3,4,5}; // works!
> >>
> >> but not this:
> >>
> >> boost::array<int> sarray(5) = {1,2,3,4,5}; // no way jose :(
> >>
> >> There's simply no way to create runtime-sized aggregates
> (that I know
> >> of)
> >> I am looking for a test suite for boost::array (if exists) to make
> >> sure I didnt break anything, and I also wanted to hear
> some opinions
> >> on the subject.
> >
> > Unfortunately that would break Boost.Array in Boost-1.34
> onwards which
> > already has a TR1-compatible partial specialisation for
> zero-sized arrays.
> >
> > I've been trying to think of what array-like objects I use
> already and how
> > this would fit in:
> >
> > C style arrays:
> > Hardly ever, except for small immutable arrays. For
> example tables of
> > coefficients for rational approximations.
> >
> > Boost.Array:
> > Mostly for fixed size tables of immutable data, test data
> for example.
> >
> > Scoped_array:
> > Useful for temporary buffers whose size is determined at
> runtime. Doesn't
> > have a container interface though, and probably mostly used for
> > interfacing
> > with legacy C API's.
> >
> > Shared_array:
> > Never used it. Might do if I wanted to write a copy-on-write
> > string/vector,
> > but that's about all.
> >
> > std::vector/std::string:
> > Used for everything else, which encompasses quite a lot :-)
> >
> > So.... you have quite a lot of competition here, and I've
> yet to see a
> > compelling reason to have yet-another-vector :-)
> >
> > Thinking out loud, the issues, seems to boil down to:
> >
> > Code size: I would be very surprised to see any difference, although
> > vector/string have "fatter" interfaces, you only pay for the member
> > functions you actually use. Indeed if vector<whatever> is
> instantiated
> > already somewhere else in the program, or if you can use
> std::string and
> > that's already in use elsewhere, then you may *save* on
> code size by
> > reusing
> > these.
> >
> > Object size: I guess your runtime-sized array would be
> sizeof(void*) in
> > size, compared to typically three times that for a vector.
> There may be
> > times when that's important - embedded systems for example
> - but then
> > unless
> > you really need a container-like interface scoped_array is
> probably a
> > better
> > bet.
> >
> > Actually I think I may have just provided a compelling
> reason for a real
> > lightweight container after all then! It would have to be called
> > something
> > other than array though :-)
> >
> > Just thinking out loud,
> >
> > John.
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk