Re: [boost] static_vector using aligned_storage

Subject: Re: [boost] static_vector using aligned_storage
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2012-12-13 05:38:28

2012/12/12 Nevin Liber <nevin_at_[hidden]>

> On 12 December 2012 15:39, Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]
> >wrote:
>
> > Personally I'd like to have exception thrown only in at(). Only this
> > method throws out_of_range exception in std::vector and boost::array. So
> > operator[], pop_back(), erase() shouldn't throw IMO. The problem is with
> > vector's methods which may throw bad_alloc exception, like push_back() or
> > insert(). I think that in general we shouldn't provide mechanisms (throw
> > exceptions) which majority of users wouldn't need. So I see a few
> possible
> > solutions:
> > 1. Leave static_vector as it is now, throwing exceptions.
> > 2. Make error handling dependent on some macro e.g.
> > BOOST_STATIC_VECTOR_USE_**EXCEPTIONS
> > 3. Use slightly different class interface and take additional template
> > parameter: static_vector<T, N, ErrHandling = use_asserts>
> > 4. Use asserts in static_vector and provide a wrapper throwing
> exceptions.
> > Or if people are concerned about the efficiency, implement a base class
> and
> > derive both implementations from it.
> >
>
> 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.
>

+1

I like the simplicity and flexibility of this approach.

And I'd add a null_allocator_unchecked for performace-critical cases ;)

Regards,
Kris