Re: [boost] [container] static_vector: fixed capacity vector update

Subject: Re: [boost] [container] static_vector: fixed capacity vector update
From: Nevin Liber (nevin_at_[hidden])
Date: 2013-01-21 13:29:27

On 21 January 2013 11:19, Andrew Hundt <athundt_at_[hidden]> wrote:

> On Mon, Jan 21, 2013 at 10:45 AM, Olaf van der Spek <ml_at_[hidden]> wrote:
> > What happened to hybrid array/vector?
>
> Strictly speaking it's not a proper superset since there are some
> fundamental interface differences between a container with a hard size
> limit of N vs one with a more flexible size limit.

I see no fundamental difference between your solution and a hybrid vector
with a null allocator.

The limitations of static_vector also provides some of its strengths.
> For instance, an individual call to push back() will never be an O(N)
> operation due to reallocation which is important when latency is
> critical.

Neither is there one in a hybrid vector with a null allocator.

> Also, for real time systems allocation is not desirable and
> hybrid_vector would require much more care to avoid allocations than
> static_vector will.
>

I need correctness first.  If I can live with a fixed upper bound, I can
use a null allocator.

> There are also some properties of hybrid_vector that place it outside
> the scope of static_vector. For instance, hybrid_vector's swap() could
> sometimes be O(1) for large N, and O(N) for small N, while
> static_vector always occupies the small N case.

And you see this as an *advantage* for your solution?  For swap, the hybrid
vector is never any worse and sometimes better than your solution.

 Ultimately, I think static_vector and hybrid_vector make the most

> sense as two separate classes.
>

Which is what it boils down to.  The rest is just rationalization.

I see your solution as a subset of hybrid vector, and if hybrid vector
exists, I don't see any reason to use yours over it.
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]