This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
std::string
allocator requirements still inconsistentSection: 27.4.3 [basic.string] Status: NAD Submitter: Bo Persson Opened: 2006-12-05 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [basic.string].
View all other issues in [basic.string].
View all issues with NAD status.
Discussion:
This is based on N2134, where 21.3.1/2 states: "... The Allocator object used shall be a copy of the Allocator object passed to the basic_string object's constructor or, if the constructor does not take an Allocator argument, a copy of a default-constructed Allocator object."
Section 21.3.2/1 lists two constructors:
basic_string(const basic_string<charT,traits,Allocator>& str ); basic_string(const basic_string<charT,traits,Allocator>& str , size_type pos , size_type n = npos, const Allocator& a = Allocator());
and then says "In the first form, the Allocator value used is copied from str.get_allocator().", which isn't an option according to 21.3.1.
[ Batavia: We need blanket statement to the effect of: ]
[ Review constructors and functions that return a string; make sure we follow these rules (substr, operator+, etc.). Howard to supply wording. ]
[
Bo adds: The new container constructor which takes only a size_type
is not
consistent with 23.2 [container.requirements], p9 which says in part:
]
All other constructors for these container types take an
Allocator&
argument (20.1.2), an allocator whose value type is the same as the container's value type. A copy of this argument is used for any memory allocation performed, by these constructors and by all member functions, during the lifetime of each container object.
[ post Bellevue: We re-confirm that the issue is real. Pablo will provide wording. ]
[ 2009-07 Frankfurt ]
Move to NAD.
Proposed resolution: