Re: [boost] boost::array support for runtime-sized arrays

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.

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
>