On Sat, Oct 15, 2011 at 4:07 PM, Peter Dimov <pdimov@pdimov.com> 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? - Jeff