Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk