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
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]> (847) 691-1404
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk