Boost logo

Boost :

From: Steven Burns (royalstream_at_[hidden])
Date: 2006-07-20 12:21:46

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.


"John Maddock" <john_at_[hidden]> wrote in message
> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at