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

From: John Maddock (john_at_[hidden])
Date: 2006-07-20 11:41:56

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.