This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
Section: 99 [allocator.concepts.members] Status: Resolved Submitter: Alberto Ganesh Barbati Opened: 2009-07-08 Last modified: 2017-02-03
Priority: Not Prioritized
View all issues with Resolved status.
I believe the two functions select_on_container_(copy|move)_construction() are over-constrained. For example, the return value of the "copy" version is (see 99 [allocator.concepts.members]/21):
Returns: x if the allocator should propagate from the existing container to the new container on copy construction, otherwise X().
Consider the case where a user decides to provide an explicit concept map for Allocator to adapt some legacy allocator class, as he wishes to provide customizations that the LegacyAllocator concept map template does not provide. Now, although it's true that the legacy class is required to have a default constructor, the user might have reasons to prefer a different constructor to implement select_on_container_copy_construction(). However, the current wording requires the use of the default constructor.
Moreover, it's not said explicitly that x is supposed to be the allocator of the existing container. A clarification would do no harm.
[ 2009-10 Santa Cruz: ]
NAD Editorial. Addressed by N2982.
Replace 99 [allocator.concepts.members]/21 with:
X select_on_container_copy_construction(const X& x);
x if the allocator should propagate from the existing container to the new container on copy construction, otherwise X().
Replace 99 [allocator.concepts.members]/25 with:
X select_on_container_move_construction(X&& x);
move(x) if the allocator should propagate from the existing container to the new container on move construction, otherwise X().