On Sun, Jul 26, 2015 at 5:54 PM, Glen Fernandes
Some feedback:
Thanks for the feedback!
1. For a given type T whose constructor can throw, and you have a loop constructing n objects of type T via std::allocator_traits<T>::construct - should you not be handling that potential construction failure? (i.e. Destroying those elements that were constructed before the constructor that throws, before re-throwing)
[snip]
(My apologies if you already do this, and I missed it).
There are two such constructors: explicit devector(size_type n, const Allocator& allocator = Allocator()) devector(size_type n, const T& value, const Allocator& allocator = Allocator()) The first one has a `construction_guard` which takes care cleanup on failure. The second one calls `opt_copy` at the end, which also has the same kind of guard if needed. The failure scenario for both constructor (and for other metods) is tested: https://github.com/erenon/container/blob/devector/test/devector_test.cpp#L22... https://github.com/erenon/container/blob/devector/test/devector_test.cpp#L26... Did I missed something?
2. size_type being unsigned int instead of std::size_t - I understand the motivation, but could this not be customized - e.g. via another policy? Or should it not instead be based on std::allocator_traits<Allocator>::size_type instead?
We could provide a way. However, using allocator_traits is not the best option, I guess, since std::allocator::size_type is size_t, and for most users unsigned would be enough. GrowthPolicy could be used, however.
3. I understand deriving from Allocator for EBO, but should that type be std::allocator_traits<Allocator>::rebind_alloc<T> instead? (And have the 'allocator_type' member typedef also be this rebound type) .
What would this buy us? The user is expected to provide an allocator for T. As far as I know, the usecase of rebind is to allocate other types with the provided allocator, e.g: nodes, in node based containers. I'm not against the idea, I just don't know how is it better. Thanks, Benedek