|
Boost : |
Subject: Re: [boost] devector feedback request
From: Benedek Thaler (thalerbenedek_at_[hidden])
Date: 2015-07-26 17:24:46
On Sun, Jul 26, 2015 at 11:13 PM, Glen Fernandes <glen.fernandes_at_[hidden]>
wrote:
>
> It's up to you. It may be more intuitive having a separate policy,
> instead of turning GrowthPolicy into GrowthAndSizePolicy.
>
I'd like to avoid having too many policies. One could argue, that the
chosen size type limits the maximum growth, thus it fits into the concept
of the GrowthPolicy. I'll think on it.
>
>
>
> 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;
> };
>
In this case, one should write:
template <class A>
struct T {
template <class Y>
using AY = typename std::allocator_traits<A>::rebind_alloc<Y>;
container1<U, AY<U>> c1;
// etc.
}
>
> .... 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.
>
I think this version obscures intent and behaviour, and encourages sloppy
use. It looks like the container uses allocator<X>, but really, it uses
allocator<Y>, which is not nice. Or maybe it's just me being too strict.
Thanks,
Benedek
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk