Subject: Re: [boost] static_vector using aligned_storage
From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2012-12-12 19:30:20
On Dec 12, 2012, at 1:39 PM, Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]> wrote:
> Andrew Hundt wrote:
>> Yes, I had proposed StaticVector.
>> Here is the repository:
>> Here is a link to the original discussion via google groups:
>> 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.
I would like to see static_vector throw an exception if you try to put too much data in it.
To me, this is analogous to not being able to allocate memory in std::vector::push_back.
For operator , no exception. -- just like vector.
For at (), throw std:: out_of_range -- just like vector
> 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.
data() is nice for passing to legacy (aka "C") interfaces.
Marshall Clow Idio Software <mailto:mclow.lists_at_[hidden]>
A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
-- Yu Suzuki
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk