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