This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++17 status.

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

Section: 21.3.3.7.3 [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.

Discussion:

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`

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