Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-10-15 19:32:45
On Sat, Oct 15, 2011 at 4:07 PM, Peter Dimov <pdimov_at_[hidden]> wrote:
> Dave Abrahams wrote:
>> > Anyway. Do you agree that the number of push_backs is typically a run
>> > time value?
>> Absolutely, 100% agreed.
> OK. So we sometimes have more elements than the static_vector can take, and
> this can't yet be a logic error because it's caused by input external to the
> program. What do we do?
So, I figure it might add some fuel to the fire if I shared what one of my
use cases has been for this sort of structure. I implemented a data
structure called "bounded_vector" which is basically the same as the
proposed "static_vector" with asserting when over-capacity (i.e., no
throwing). My problem required storing a variable but compile-time-bounded
number of not-necessarily-default-constructible-objects in an array.
Specifically, I was storing some representation of the sub-simplex
intersections between two d-dimensional simplices, where d was a
compile-time constant (typically 2 or 3). The number of such intersections
is bounded in terms of the dimension d, and this was a computational
intensive part of the application, so avoiding heap access was desirable.
To me, something like the above is a shoe-in use case for static_vector /
bounded_vector: you have a variable but compile-time upper bound on the
size, and, to boot, your value_type is not default constructible. I never
thought of static_vector as a "drop-in replacement" for std::vector. As
Dave alluded to in another message, wouldn't Thorsten's proposed AutoBuffer
(which falls back to the heap when the immediate storage is exceeded) be
more appropriate in cases where you want to optimize for small array sizes
but also want to account for larger arrays?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk