On Dec 12, 2012, at 1:39 PM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> 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/discu...
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@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki