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@johnmaddock.co.uk> wrote in message news:005e01c6ac13$0cd8f8e0$ea8c0252@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