Re: [boost] Interest in StaticVector - fixed capacity vector

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
reasonable.

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
drastic:

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
class.

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.

Regards,
Nate