Question

The new C++11 standard requires STL implementations to support stateful allocators in containers. Do main STL implementations (Visual Studio 2008, 2010, libstdc++) comply to this requirement now? I found nothing about this in MSDN or in libstdc++ documentation.

Answer 1

Looks like the feature of stateful allocators in STL containers is widely supported already. In most cases statefullness of the allocator does not cause trouble. What is not widely supported yet is the new standard’s way of handling the problematic situations (swap of a container(whether to swap the allocator too), splice of lists).

This thread says:

in code for most current standard libraries (including Dinkumware’s as used by MS), stateful allocators are supported

This tread (libstdc++, 2004) says (if i understood correctly):

We already support allocators where l1.get_allocator() != l2.get_allocator(). What we don’t do is make any special provisions to detect those allocators in splice() and swap().

This blog entry (libstdc++, 2009) says:

Existing containers in C++0x mode are now more efficient together with stateful allocators (i.e., no allocators are created on the fly at element construction time).

This document says about the new libc++ library:

All containers meet all of the latest allocator requirements
which fully support stateful allocators.
– Space for stateless allocators optimized away.

EASTL supports statefull allocators.

This thread contains an interesting dispute about how portable this feature is.

So most STL implementations support statefull allocators, which means that they do not create additional instances of the allocator type under the hood, but store the client-supplied allocator instance and all allocations/deallocations are done via that. However the way that they handle swapping and list::splice is undocumented, non-portable.

UPDATE: VS2008’s STL requires the allocators to have the templated copy constructor, which IMO makes the most important use of custom allocators impossible: simple segregated storage.

For whoever is not satisfied with the current state of stateful allocators in STL, I recommend to consider Boost.Intrusive and Boost.Container.