Section: 18.104.22.168 [allocator.requirements] Status: C++17 Submitter: Daniel Krügler Opened: 2010-11-17 Last modified: 2017-07-30
View other active issues in [allocator.requirements].
View all other issues in [allocator.requirements].
View all issues with C++17 status.
During the Batavia meeting it turned out that there is a definition hole for types satisfying the Allocators requirements: The problem became obvious when it was discussed whether all swap functions of Containers with internal data handles can be safely tagged with noexcept or not. While it is correct that the implicit swap function of an allocator is required to be a no-throw operation (because move/copy-constructors and assignment operators are required to be no-throw functions), there are no such requirements for specialized swap overloads for a particular allocator.But this requirement is essential because the Containers are required to support swappable Allocators, when the value allocator_traits<>::propagate_on_container_swap evaluates to true.
[2011-02-10 Alberto, Daniel, and Pablo collaborated on the proposed wording]
The proposed resolution (based on N3225) attempts to solve the following problems:
[2011-04-08 Pablo comments]
I'm implementing a version of list now and I actually do find it impossible to write an exception-safe assignment operator unless I can assume that allocator assignment does not throw. (The problem is that I use a sentinel node and I need to allocate a new sentinel using the new allocator without destroying the old one -- then swap the allocator and sentinel pointer in atomically, without risk of an exception leaving one inconsistent with the other.Please update the proposed resolution to add the nothrow requirement to copy-assignment.
[2014-02-14 Issaquah: Move to Ready]
Fix a couple of grammar issues related to calling swap and move to Ready.
Adapt the following three rows from Table 44 — Allocator requirements:
Table 44 — Allocator requirements Expression Return type Assertion/note
Default X::propagate_on_container_copy_assignment Identical to or derived from true_type
true_type only if an allocator of type X should be copied
when the client container is copy-assigned.
false_type X::propagate_on_container_move_assignment Identical to or derived from true_type
true_type only if an allocator of type X should be moved
when the client container is move-assigned.
false_type X::propagate_on_container_swap Identical to or derived from true_type
true_type only if an allocator of type X should be swapped
when the client container is swapped.
Following 22.214.171.124 [allocator.requirements] p. 3 insert a new normative paragraph:
Modify 26.2.1 [container.requirements.general] p. 8 and p. 9 as indicated:
8 - [..] The allocator may be replaced only via assignment or swap(). Allocator replacement is performed by copy assignment, move assignment, or swapping of the allocator only if allocator_traits<allocator_type>::propagate_on_container_copy_assignment::value, allocator_traits<allocator_type>::propagate_on_container_move_assignment::value, or allocator_traits<allocator_type>::propagate_on_container_swap::value is true within the implementation of the corresponding container operation.9 - The expression a.swap(b), for containers a and b of a standard container type other than array, shall exchange the values of a and b without invoking any move, copy, or swap operations on the individual container elements.
The behavior of a call to a container's swap function is undefined unless the objects being swapped have allocators that compare equal or allocator_traits<allocator_type>::propagate_on_container_swap::value is true. In all container types defined in this Clause, the member get_allocator() returns a copy of the allocator used to construct the container or, if that allocator has been replaced, a copy of the most recent replacement. Any Compare, Pred, or Hash objectsbelonging to a and b shall be swappable and shall be exchanged by unqualified calls to non-memberswap . If allocator_traits<allocator_type>::propagate_on_container_swap::value is true, then the allocators of a and b shall also be exchanged using an unqualified call to non-memberswap . Otherwise, theyshall not be swapped, and the behavior is undefined unless a.get_allocator() == b.get_allocator(). Every iterator referring to an element in one container before the swap shall refer to the same element in the other container after the swap. It is unspecified whether an iterator with value a.end() before the swap will have value b.end() after the swap.