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.