2579. Inconsistency wrt Allocators in basic_string assignment vs. basic_string::assign

Section: [string.assign] Status: C++17 Submitter: Marshall Clow Opened: 2016-01-05 Last modified: 2017-07-30

Priority: 0

View all other issues in [string.assign].

View all issues with C++17 status.


In issue 2063, we changed the Effects of basic_string::assign(basic_string&&) to match the behavior of basic_string::operator=(basic_string&&), making them consistent.

We did not consider basic_string::assign(const basic_string&), and its Effects differ from operator=(const basic_string&).

Given the following definition:

typedef std::basic_string<char, std::char_traits<char>, MyAllocator<char>> MyString;

MyAllocator<char> alloc1, alloc2;
MyString string1("Alloc1", alloc1);
MyString string2(alloc2);

the following bits of code are not equivalent:

string2 = string1;       // (a) calls operator=(const MyString&)
string2.assign(string1); // (b) calls MyString::assign(const MyString&)

What is the allocator for string2 after each of these calls?

  1. If MyAllocator<char>::propagate_on_container_copy_assignment is true, then it should be alloc2, otherwise it should be alloc1.

  2. alloc2 [string.assign]/1 says that (b) is equivalent to assign(string1, 0, npos), which eventually calls assign(str.data() + pos, rlen). No allocator transfer there.

[2016-02, Issues Telecon]

P0; move to Tentatively Ready.

Proposed resolution:

This wording is relative to N4567.

  1. Modify [string.assign] p.1 as indicated:

    basic_string& assign(const basic_string& str);

    -1- Effects: Equivalent to *this = strassign(str, 0, npos).

    -2- Returns: *this.