Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-10-19 02:36:18
Le 18/10/11 19:44, Andrew Hundt a écrit :
> On Sat, Oct 15, 2011 at 5:16 PM, Nathan Ridge<zeratul976_at_[hidden]> wrote:
>> After reading this thread again, it seems to me that the reason we
>> can't reach an agreement is that different people are proposing
>> two fundamentally different ways of using static_vector:
>> 1) As a variant of [std|boost]::array where not all the elements are
>> constructed/used at the same time, and which keeps track of
>> how many elements are currently in use.
>> 2) As a variant of std::vector which keeps its memory on the
>> stack, and which is used, literally, as a drop-in replacement
>> for std::vector, in the sense that the developer was using
>> std::vector, but then identified that in non-exceptional
>> situations the actual number of elements used is below a
>> certain threshold, and the program could use the
>> optimization of not allocating memory dynamically.
> Nate seems to have provided the best analysis of the situation that I
> have seen in the thread.
>> But isn't use-case 2 much better served by a vector that degrades
>> gracefully by falling back to using the heap? I just can't see how
>> throwing serves anyone's purpose well.
> As Dave Abrahams suggests, I agree that the best behavior for case (2)
> is falling back to the heap after exhausting the buffer, which
> conveniently fits the functionality provided by AutoBuffer. Therefore,
> I think StaticVector should focus on use case (1).
> I'll probably attempt to make StaticVector fulfill use case (1) with
> bounds checking performed using assert, in a way that makes it viable
> for use internally within AutoBuffer as well if the writer of that
> library desired to. The way I see things, if I implement StaticVector
> using assert, someone can inherit from my class and add exceptions if
> desired. I may be mistaken, but one could not do the same the other
> way around without any sacrifice, since some implementations of
> exceptions incur performance penalties.
I don't see the advantage to use internally AutoBuffer here, but maybe
I'm missing something evident.
> As for check/unchecked bounds, I'll start with push_back being
> checked, and provide unchecked_push_back + unchecked_insert. I know it
> is less popular than a policy based implementation but I feel like
> there will be reduced overhead for compiler implementations with less
> effective optimizations, though this is based only on others' comments
> earlier on in the thread. Since this is (for me at least) designed to
> also be useful for embedded applications which may have stricter
> requirements, I find this to be a sensible choice.
I will add that the push_back is checked only in debug mode as it will
Then the unchecked version lost its utility on release mode.
> Please rip my choices apart for me, so I can correct them now before I
> write more code :-)
> I have one additional question regarding the size. It was requested
> that I use boost::uint_value_t<N>::least, but I am concerned this
> would inhibit uses where one inherits from StaticVector to add
> functionality such as what is found in AutoBuffer. Should I stick to
> std::size_t, boost::uint_value_t<N>::least, or allow the size type to
> be set with a template parameter?
You can always add a size_type template parameter that is defaulted to
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk