Boost logo

Boost :

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

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

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