Question

There is a template parameter for STL containers to chose a custom allocator. It took a while, but I think I understand how it works. Somehow it isn’t really nice because the given allocator type isn’t used directly but it is rebound to the allocator of another type. Finally I can work with it.

After reading the API I recognized that there is also the possibility to give allocators as constructor parameter. But how do I know which kind of allocator the container uses, if it internally rebinds the given allocator from the template parameter?

Additionally I read that C++11 now uses scoped allocators which allow to reuse the allocator of a container for its containing containers. How does the implementation of a scoped allocator enabled container roughly differs from one that is not aware of scoped containers?

Unfortunately I wasn’t able to find anything that could explain this. Thanks for answers!

Answer 1

But how do I know which kind of allocator the container uses, if it
internally rebinds the given allocator from the template parameter?

Always supply an Allocator<T> to the constructor (where T is the value_type of the container). The container will convert it to an Allocator<U> is necessary where U is some internal data structure of the container. The Allocator is required to supply such converting constructors, e.g.:

template <class T> class allocator {
    ...
    template <class U> allocator(const allocator<U>&);

Additionally I read that C++11 now uses scoped allocators which allow
to reuse the allocator of a container for its containing containers.

Well, to be more precise, C++11 has an allocator adaptor called scoped_allocator_adaptor:

template <class OuterAlloc, class... InnerAllocs>
class scoped_allocator_adaptor : public OuterAlloc
{
    ...
};

From C++11:

The class template scoped_allocator_adaptor is an allocator template
that specifies the memory resource (the outer allocator) to be used by
a container (as any other allocator does) and also specifies an inner
allocator resource to be passed to the constructor of every element
within the container. This adaptor is instantiated with one outer and
zero or more inner allocator types. If instantiated with only one
alloca- tor type, the inner allocator becomes the
scoped_allocator_adaptor itself, thus using the same allocator
resource for the container and every element within the container and,
if the elements themselves are con- tainers, each of their elements
recursively. If instantiated with more than one allocator, the first
allocator is the outer allocator for use by the container, the second
allocator is passed to the constructors of the container’s elements,
and, if the elements themselves are containers, the third allocator is
passed to the elements’ elements, and so on. If containers are nested
to a depth greater than the number of allocators, the last allocator
is used repeatedly, as in the single-allocator case, for any remaining
recursions. [Note: The scoped_allocator_adaptor is derived from the
outer allocator type so it can be substituted for the outer allocator
type in most expressions. — end note ]

So you only get the scoped allocators behavior if you specify a scoped_allocator_adaptor as the allocator for your container.

How does the implementation of a scoped allocator enabled container
roughly differs from one that is not aware of scoped containers?

The key is that the container now deals with its allocator via a new class called allocator_traits instead of dealing with the allocator directly. And the container must use allocator_traits for certain operations such as constructing and destructing value_types in the container. The container must not talk to the allocator directly.

For example, allocators may provide a member called construct that will construct a type at a certain address using the given arguments:

template <class T> class Allocator {
     ...
    template<class U, class... Args>
        void construct(U* p, Args&&... args);
};

If an allocator does not provide this member, allocator_traits will provide a default implementation. In any event, the container must construct all value_types using this construct function, but using it through allocator_traits, and not using the allocator directly:

allocator_traits<allocator_type>::construct(the_allocator, *ugly details*);

The scoped_allocator_adaptor provides custom construct functions which allocator_traits will forward to which take advantage of the uses_allocator traits and passes the correct allocator along to the value_type constructor. The container remains blissfully ignorant of these details. The container only has to know that it must construct the value_type using the allocator_traits construct function.

There are more details the container must have to deal with to correctly handle stateful allocators. Though these details too are dealt with by having the container not make any assumptions but get all properties and behaviors via allocator_traits. The container can not even assume that pointer is T*. Rather this type is found by asking allocator_traits what it is.

In short, to build a C++11 container, study up on allocator_traits. And then you get scoped allocator behavior for free when your clients use the scoped_allocator_adaptor.