Re: [Boost-users] custom allocators Re:pool_alloc

Subject: Re: [Boost-users] custom allocators Re:pool_alloc
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2010-03-19 15:50:50

On 19 March 2010 15:12, Eric Whitcombe <ericwsf_at_[hidden]> wrote:
>
> I don't know what you mean when you say "vector is the only container that
> actually allocates from passed-in allocator." All containers allocate memory
> for a copy of the element you add. That is why one of the requirements for
> user-defined types to be stored in STL containers is that they have to be
> copy-constructible.
>

I mean that all the other containers need to rebind the allocator, so
for consistency, it seems like vector should too.  But then once
everything is rebinding the allocator, it no longer makes sense to
parametrise the passed-in allocator by the type, since it's just going
to rebind it.

Basically, the most basic way would just be to do:

template <typename T = void>
class allocator {
   ... as currently ...
};

template <>
class allocator<void> {
    template <typename T>
    struct rebind { typedef allocator<T> type; };
};

Then you would just pass std::allocator<> to all the containers, and
everything could easily be made to work.

>
> I'd say that has more to do with your compiler and the general hazards of
> recursion. There is no infinite capacity for recursion whether it be your
> compiler's symbol table capacty (or it's inability to simplify the symbol
> table) or the limits on stack space at run time.
>

The point is that (using A for std::allocator and V for std::vector), a

    V<V<V<T>>>

is actually a

    V<V<V<T,A<T>>, A<V<T,A<T>>>>,A<V<V<T,A<T>>, A<V<T,A<T>>>>>>

because the names are exponential in depth, rather than linear in
depth as they ought to be.

With a non-parametrised allocator, it'd just be

    V<V<V<T,A>,A>,A>

which is much easier to deal with.