Title
select_on_container_(copy|move)_construction over-constrained
Status
resolved
Section
[allocator.concepts.members]
Submitter
Alberto Ganesh Barbati

Created on 2009-07-08.00:00:00 last changed 162 months ago

Messages

Date: 2010-10-21.18:28:33

Proposed resolution:

Replace [allocator.concepts.members]/21 with:

X select_on_container_copy_construction(const X& x);

-21- Returns: x if the allocator should propagate from the existing container to the new container on copy construction, otherwise X(). an allocator object to be used by the new container on copy construction. [Note: x is the allocator of the existing container that is being copied. The most obvious choices for the return value are x, if the allocator should propagate from the existing container, and X(). — end note]

Replace [allocator.concepts.members]/25 with:

X select_on_container_move_construction(X&& x);

-25- Returns: move(x) if the allocator should propagate from the existing container to the new container on move construction, otherwise X(). an allocator object to be used by the new container on move construction. [Note: x is the allocator of the existing container that is being moved. The most obvious choices for the return value are move(x), if the allocator should propagate from the existing container, and X(). — end note]

Date: 2010-12-05.00:09:22

[ 2009-10 Santa Cruz: ]

NAD EditorialResolved. Addressed by N2982.

Date: 2009-07-08.00:00:00

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 [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.

History
Date User Action Args
2010-12-05 00:09:22adminsetstatus: nad editorial -> resolved
2010-10-21 18:28:33adminsetmessages: + msg1011
2010-10-21 18:28:33adminsetmessages: + msg1010
2009-07-08 00:00:00admincreate