$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] devector feedback request
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2015-07-26 17:13:24
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