Subject: Re: [boost] static_vector using aligned_storage
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2012-12-12 16:39:59
Andrew Hundt wrote:
> Yes, I had proposed StaticVector.
>
> Here is the repository:
> https://github.com/ahundt/Boost.StaticVector
>
> Here is a link to the original discussion via google groups:
> https://groups.google.com/d/topic/boost-developers-archive/4n1QuJyKTTk/discussion
>
> I would be interested in working with you to complete either my version or
> yours. Did you have any thoughts or questions regarding my implementation?
> There are a few items related to my implementation on the github ticket
> list that came from the discussion thread that need resolving before the
> next round, but nothing too bad.
>
Yes, a few things regarding the interface.
I see that the most nagging thing is asserts vs. exceptions issue. I
remember that there were quite a discussion about it.
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.
I'd prefer everything besides 1.
The rest are details.
For example, I'd consider simplifying the interface and moving it closer
to vector than array, e.g. making capacity() non-static or removing full().
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. I'd rather hide those. Also, I don't know
if fill() and assign() is needed in this kind of container, but those
certainly don't harm anyone.
Regards,
Adam