Boost C++ Libraries of the most highly regarded and expertly designed C++ library projects in the world. Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

This is the documentation for an old version of Boost. Click here to view this page for the latest version.

C++11 Conformance

Move and Emplace
Stateful allocators and Scoped allocators
Initializer lists

Boost.Container aims for full C++11 conformance except reasoned deviations, backporting as much as possible for C++03. Obviously, this conformance is a work in progress so this section explains what C++11 features are implemented and which of them have been backported to C++03 compilers.

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.

Many C++ container implementors felt C++03 guarantees were too weak and started to offer extensions. Boost.Container, following Boost.Interprocess containers experience supporting stateful allocators, offers the following guarantees:

  • Allocators are copy-constructed in copy/move constructors
  • If possible, a single allocator is hold to construct value_type and this allocator is copy constructed from the user-supplied allocator object during container's constructor. If the container needs an auxiliary allocator (e.g. a array allocator used by deque or stable_vector), that allocator is also copy-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).
  • Allocators are compared for equality when swapping containers. If allocators don't compare equal allocators are swapped using an unqualified swap call.

C++11 further improves stateful allocator support through the Scoped Allocators model, using classes like std::scoped_allocator_adaptor and std::allocator_traits. [*Boost.Container does not support it yet, but there are plans to do so and backport scoped allocator support to C++03 compilers.

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.

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>.

  • In 1998, admitting that the committee made a mistake was controversial. Since then Java has had to deprecate such significant portions of their libraries that the idea C++ would be ridiculed for deprecating a single minor template specialization seems quaint.
  • vector<bool> is not a container and vector<bool>::iterator is not a random-access iterator (or even a forward or bidirectional iterator either, for that matter). This has already broken user code in the field in mysterious ways.
  • vector<bool> forces a specific (and potentially bad) optimization choice on all users by enshrining it in the standard. The optimization is premature; different users have different requirements. This too has already hurt users who have been forced to implement workarounds to disable the 'optimization' (e.g., by using a vector<char> and manually casting to/from 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.