boostorg/container
1
0
Fork 1
mirror of https://github.com/boostorg/container.git synced 2025-08-02 22:14:26 +02:00
Code Issues Packages Projects Releases Wiki Activity

Documentation update

Browse Source 
[SVN r76177]
This commit is contained in:
Ion Gaztañaga
2011-12-26 16:37:49 +00:00
parent 3d8439595f
commit ba4a746a77
1 changed files with 22 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
doc/container.qbk
View File

@@ -412,7 +412,7 @@ a finite (10) number of parameters.
[endsect]
[section:alloc_traits_move_traits Stateful allocators and Scoped allocators]
[section:alloc_traits_move_traits Stateful allocators]
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
@@ -422,24 +422,18 @@ to suppose two allocators of the same type always compare equal (that means that
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 [@http://www.boost.org/libs/interprocess/ 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
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf
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.
Scoped Allocators model]. [@http://en.cppreference.com/w/cpp/memory/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).
[endsect]
@@ -451,7 +445,14 @@ to C++03 compilers.
[endsect]
[section:Vector_bool vector<bool>]
[section:forward_list `forward_list<T>`]
[*Boost.Container] does not offer C++11 `forward_list` container yet, but it will be available in future
versions.
[endsect]
[section:Vector_bool `vector<bool>`]
`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
@@ -591,6 +592,9 @@ use [*Boost.Container]? There are several reasons for that:
[@https://svn.boost.org/trac/boost/ticket/6287 #6287],
[@https://svn.boost.org/trac/boost/ticket/4383 #4383].
* Added `allocator_traits` support for both C++11 and C++03
compilers through an internal `allocator_traits` clone.
[endsect]
[section:release_notes_boost_1_48_00 Boost 1.48 Release]