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

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

Regards,
Adam