Subject: Re: [boost] devector feedback request
From: Benedek Thaler (thalerbenedek_at_[hidden])
Date: 2015-07-26 14:53:45
On Sun, Jul 26, 2015 at 5:54 PM, Glen Fernandes <glen.fernandes_at_[hidden]>
> 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
> (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 =
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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk