|
Boost : |
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
> 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.
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