Re: [boost] static_vector using aligned_storage

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