boost_mirror/unordered
1
0
Fork 0
mirror of https://github.com/boostorg/unordered.git synced 2025-05-11 21:44:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

Document changes to allocator use

Browse Source
This commit is contained in:
Daniel James 2017-04-18 10:14:26 +01:00
parent ef05493c83
commit 8c9080f11f
1 changed files with 24 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
doc/compliance.qbk
View File

@ -51,23 +51,32 @@ Due to imperfect move emulation, some assignments might check
`propagate_on_container_copy_assignment` on some compilers and `propagate_on_container_copy_assignment` on some compilers and
`propagate_on_container_move_assignment` on others. `propagate_on_container_move_assignment` on others.
The use of the allocator's construct and destruct methods might be a bit [endsect]
surprising.
Nodes are constructed and destructed using the allocator, but the elements
are stored in aligned space within the node and constructed and destructed
by calling the constructor and destructor directly.
In C++11 the allocator's construct function has the signature: [section:construction Construction/Destruction using allocators]
template <class U, class... Args> The following support is required for full use of C++11 style
void construct(U* p, Args&&... args); construction/destruction:
which supports calling `construct` for the contained object, but * Variadic templates.
most existing allocators don't support this. If member function detection * Piecewise construction of `std::pair`.
was good enough then with old allocators it would fall back to calling * Either `std::allocator_traits` or expression SFINAE.
the element's constructor directly but in general, detection isn't good
enough to do this which is why Boost.Unordered just calls the constructor This is detected using Boost.Config. The macro
directly every time. In most cases this will work okay. `BOOST_UNORDERED_CXX11_CONSTRUCTION` will be set to 1 if it is found, or 0
otherwise.
When this is the case `allocator_traits::construct` and
`allocator_traits::destroy` will always be used, apart from when piecewise
constructing a `std::pair` using `boost::tuple` (see [link
unordered.compliance.pairs below]), but that should be easily avoided.
When support is not available `allocator_traits::construct` and
`allocator_traits::destroy` are never called.
[endsect]
[section:pointer_traits Pointer Traits]
`pointer_traits` aren't used. Instead, pointer types are obtained from `pointer_traits` aren't used. Instead, pointer types are obtained from
rebound allocators, this can cause problems if the allocator can't be rebound allocators, this can cause problems if the allocator can't be
@ -77,6 +86,7 @@ is used to obtain a const pointer.
[endsect] [endsect]
[#unordered.compliance.pairs]
[section:pairs Pairs] [section:pairs Pairs]
Since the containers use `std::pair` they're limited to the version Since the containers use `std::pair` they're limited to the version