Boost logo

Boost :

Subject: Re: [boost] [container] static_vector: fixed capacity vector update
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-01-21 16:07:18

Jeffrey Lee Hellrung, Jr. wrote:
> I would expect sizeof( static_vector ) < sizeof( hybrid_vector ) (even with
> EBO used for storing the allocator in the latter case), as hybrid_vector
> needs to discriminate between using internal and using external storage.
> Additionally, this will sometimes necessitate more branching and/or
> indirection in hybrid_vector than in static_vector for the same operation.
> Well, really, that's all just a guess, I haven't actually gone and
> implemented each myself. And it's assuming that hybrid_vector< T, N,
> null_allocator<T> > isn't special-cased to behave like a
> static_vector<T,N>, because, at that point, now we're just arguing over
> names.

Yes. It would be slower and consume more memory. It wouldn't be suitable
for people who needs an array replacement instead of vector
optimization. A replacement allowing to store objects with no default
ctors defined or to use vector's functionality with this array. So maybe
if the name included "array" of "buffer" instead of "vector" the
reception would be better.

In fact one of static_vector purposes is to be used as a part of the
other container, not only as internals of the hybrid_vector. I'm using
similar container in my R-tree and if I was forced to use hybrid_vector
I'd rather write my own container (which I did).


Boost list run by bdawes at, gregod at, cpdaniel at, john at