Subject: Re: [boost] static_vector using aligned_storage
From: Nevin Liber (nevin_at_[hidden])
Date: 2012-12-12 17:57:04
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
> 1. Leave static_vector as it is now, throwing exceptions.
> 2. Make error handling dependent on some macro e.g.
> 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.
I don't know if methods returning pointers to internal elements (data() and
> c_array()) are necessary in resizable container, especially if those are
> really aligned_storages.
data() certainly is. Again, I believe the interface should be as close to
a superset of C++11 std::vector as possible. I know I'd like to use it as
a drop-in replacement for std::vector. Every arbitrary difference makes it
a less useful class.
-- Nevin ":-)" Liber <mailto:nevin_at_[hidden]> (847) 691-1404
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk