Subject: Re: [boost] static_vector using aligned_storage
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-12-15 17:59:28
on Thu Dec 13 2012, Gottlob Frege <gottlobfrege-AT-gmail.com> wrote:
> On Wed, Dec 12, 2012 at 7:30 PM, Marshall Clow <mclow.lists_at_[hidden]>wrote:
>> On Dec 12, 2012, at 3:26 PM, Olaf van der Spek <ml_at_[hidden]> wrote:
>> > On Wed, Dec 12, 2012 at 11:57 PM, Nevin Liber <nevin_at_[hidden]>
>> >> Another possible solution is to fall back on an allocator if there isn't
>> >> enough room in the embedded storage. The signature would be something
>> >> static_vector<T, N, A = std::allocator<T>>
>> >> And you could provide null_allocator_assert and null_allocator_throw as
>> >> options (or make one of those the default), as it is now the
>> >> of the allocator, not static_vector, to throw or not throw.
>> > That'd make it more like a hybrid_vector, but it's certainly a good idea.
>> > It's like a string with a small string optimization.
>> To me, that's a different container.
>> -- Marshall
> And in fact it *is* a different container. Since the allocator is part of
> the type, it is a different type. :-) For once, having the allocator as
> part of the type is a good thing.
> I posit:
> 1. we want a hybrid "small string optimization" vector anyhow - I think it
> would be useful in many places
> 2. thus assume we have hybrid_vector
> 3. would we then want static_vector to be different, or just a typedef of
> hybrid_vector with a particular null_allocator?
Hmm, it will be interesting to see how this works. Now that the
weasel-wording is gone, the allocator's pointer type, etc., have
specific meanings that might not be compatible with stack memory.
-- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk