|
Boost : |
From: Steven Burns (royalstream_at_[hidden])
Date: 2006-07-20 11:17:27
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.
Steven
"me22" <me22.ca_at_[hidden]> wrote in message
news:fa28b9250607192031j73ddcee0q4f892335e06a0d8_at_mail.gmail.com...
> On 7/19/06, Steven Burns <royalstream_at_[hidden]> wrote:
>> Recently I came up with a modified version of boost::array that supports
>> runtime sized arrays.
>>
>> It is backwards compatible:
>>
>> boost::array<int, 10> sarray;
>>
>> but it can be used this way now:
>>
>> boost::array<int> darray(10);
>>
> How did you implement this? A partial specialisation for when the
> size is the new default of -1 or something?
>
> Of course, with that constructor you no longer have an aggregate,
> which is one of the big advantages of boost::array.
>
>> I realize you could simply use std::vector, but sometimes all you want is
>> a
>> fixed-size array (but sized at runtime). Besides, I am not sure about the
>> overhead involved with std::vector for these simple scenarios.
>>
> Up to your implementation, but for most I'd expect it to be only the
> one extra pointer needed per container to hold the capacity
> information. Check to see whether in your implementation the initial
> capacity is the same as the size after construction from a size.
>
> I don't think there'd be any speed difference.
>
> ~ Scott McMurray
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk