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