614. std::string allocator requirements still inconsistent

Section: 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: ]

1. If an allocator is passed in, use it, or,
2. If a string is passed in, use its allocator.

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