For compilers with rvalue references and for those C++03 types that use Boost.Move rvalue reference emulation Boost.Container supports all C++11 features related to move semantics: containers are movable, requirements for value_type are those specified for C++11 containers.

For compilers with variadic templates, Boost.Container supports placement insertion (emplace, ...) functions from C++11. For those compilers without variadic templates support Boost.Container uses the preprocessor to create a set of overloads up to a finite (10) number of parameters.

C++03 was not stateful-allocator friendly. For compactness of container objects and for simplicity, it did not require containers to support allocators with state: Allocator objects need not be stored in container objects. It was not possible to store an allocator with state, say an allocator that holds a pointer to an arena from which to allocate. C++03 allowed implementors to suppose two allocators of the same type always compare equal (that means that memory allocated by one allocator object could be deallocated by another instance of the same type) and allocators were not swapped when the container was swapped.

C++11 further improves stateful allocator support through std::allocator_traits. std::allocator_traits is the protocol between a container and an allocator, and an allocator writer can customize its behaviour (should the container propagate it in move constructor, swap, etc.?) following allocator_traits requirements. Boost.Container not only supports this model with C++11 but also backports it to C++03.

If possible, a single allocator is hold to construct value_type. If the container needs an auxiliary allocator (e.g. a array allocator used by deque or stable_vector), that allocator is also constructed from the user-supplied allocator when the container is constructed (i.e. it's not constructed on the fly when auxiliary memory is needed).

C++11 improves stateful allocators with the introduction of std::scoped_allocator_adaptor class template. scoped_allocator_adaptor is instantiated with one outer allocator and zero or more inner allocators.

A scoped allocator is a mechanism to automatically propagate the state of the allocator to the subobjects of a container in a controlled way. If instantiated with only one allocator 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 containers, 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.

Boost.Container implements its own scoped_allocator_adaptor class and backports this feature also to C++03 compilers. Due to C++03 limitations, in those compilers the allocator propagation implemented by scoped_allocator_adaptor::construct functions will be based on traits(constructible_with_allocator_suffix and constructible_with_allocator_prefix) proposed in N2554: The Scoped Allocator Model (Rev 2) proposal. In conforming C++11 compilers or compilers supporting SFINAE expressions (when BOOST_NO_SFINAE_EXPR is NOT defined), traits are ignored and C++11 rules (is_constructible<T, Args..., inner_allocator_type>::value and is_constructible<T, allocator_arg_t, inner_allocator_type, Args...>::value) will be used to detect if the allocator must be propagated with suffix or prefix allocator arguments.

Boost.Container does not support initializer lists when constructing or assigning containers but it will support it for compilers with initialized-list support. This feature won't be backported to C++03 compilers.

Boost.Container does not offer C++11 forward_list container yet, but it will be available in future versions.

vector<bool> specialization has been quite problematic, and there have been several unsuccessful tries to deprecate or remove it from the standard. Boost.Container does not implement it as there is a superior Boost.DynamicBitset solution. For issues with vector<bool> see papers vector<bool>: N1211: More Problems, Better Solutions, N2160: Library Issue 96: Fixing vector<bool>, N2204 A Specification to deprecate vector<bool>.

So boost::container::vector<bool>::iterator returns real bool references and works as a fully compliant container. If you need a memory optimized version of boost::container::vector<bool> functionalities, please use Boost.DynamicBitset.