Benedek Thaler wrote:
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.
Ah, I see. Looks good!
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.
It's up to you. It may be more intuitive having a separate policy, instead of turning GrowthPolicy into GrowthAndSizePolicy.
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.
It only enables someone to supply an allocator type without having to supply the rebound allocator type themselves. e.g. The following code: template<class A> struct T { container1<U, A> c1; container2<V, W, A> c2; container3<X, A> c3; }; .... looks cleaner than: template<class A> struct T { container1<U, typename std::allocator_traits<A>::rebind_alloc<U> > c1; container2<V, W, typename std::allocator_traits<A>::rebind_alloc<V> > c2; container3<X, typename std::allocator_traits<A>::rebind_alloc<X> > c3; }; I know that some standard library vendors do this already: e.g. Using Dinkumware with Intel C++, the following will compile { std::vector<int, std::allocator<void> > v; v.push_back(1); } Others do not: e.g. Using libc++ with Clang there is a static_assert "Allocator::value_type must be the same as value_type". It's up to you. Personally I think the former behavior is better, and if it isn't tolerable by the standard, it should be. Best, Glen