Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Nathan Ridge (zeratul976_at_[hidden])
Date: 2011-10-15 17:16:04
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.
It's clear to me that for use (1), exceeding the bound of the
static_vector is a logic error and therefore should be undefined
behaviour, whereas for (2), exceeding the bound of the static_vector
is not a logic error and therefore throwing an exception is
My own previous arguments for not throwing were based on the
assumption that the use case is (1), without giving (2) much thought.
It's been suggested (including by me) that we use a policy or other
technique for accommodating both use cases within the same class.
However, upon some reflection, I'd like to propose something more
Let's not have a class that serves two conceptually different
purposes at all. It would confuse people, and lead to more buggy
code, as developers conflate these two fundamentally different
concepts in their head because they are both served by the same
Of course, both use cases are worthwhile and deserve having
a class for them in boost, and one's push_back should assert
and the other's should throw. We can call one capacity_array
and the other stack_vector, or whatever better names we come
up with - but let's not give them the same name, when they are
very different beasts.
Now the implementor of these classes can implement them like this:
typedef boost::detail::static_vector<T, AssertPolicy> capacity_array;
typedef boost::detail::static_vector<T, ThrowPolicy> stack_vector;
if they so choose - but the user doesn't need to know that, and should
not have access to the underlying static_vector class, which does not
correspond to any clear concept.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk