Home | Libraries | People | FAQ | More |
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.
C++11 further improves stateful allocator support through the Scoped
Allocators model. 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).
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>.
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.