Re: [boost] static_vector using aligned_storage

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]>
>> wrote:
>> >> 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
>> like
>> >>
>> >> 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
>> responsibility
>> >> 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