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

### 3006. Constructing a `basic_stringbuf` from a `string` — where does the allocator come from?

Section: 29.8.2.2 [stringbuf.cons] Status: Resolved Submitter: Marshall Clow Opened: 2017-08-02 Last modified: 2020-11-09

Priority: 3

View all other issues in [stringbuf.cons].

View all issues with Resolved status.

Discussion:

Consider the following constructor from 29.8.2.2 [stringbuf.cons] before p3:

>     explicit basic_stringbuf(
>       const basic_string<charT, traits, Allocator>& s,
>       ios_base::openmode which = ios_base::in | ios_base::out);

In [stringbuf.cons]/3, it says:

> Effects: Constructs an object of class `basic_stringbuf`, initializing the base class with `basic_streambuf()` (30.6.3.1), and initializing `mode` with `which`. Then calls `str(s)`.

But that doesn't mention where the allocator for the `basic_stringbuf` comes from. Until recently, most implementations just default constructed the allocator. But that requires that the allocator be default constructible.

This bug was filed against libc++ for this case.

I think that the `basic_stringbuf` should be constructed with a copy of the allocator from the string.

[2017-11-01, Marshall comments]

There exist two related proposals, namely P0407R1 and P0408R2.

[2017-11 Albuquerque Wednesday night issues processing]

Priority set to 3

[2020-05-02 Daniel comments]

It seems that this issue is now resolved by the proposal P0408R7, accepted in Cologne 2019.

The paper clarified that the allocator is provided based on the effect of initializing the exposition-only `basic_string buf` with the provided `basic_string argument s` (Which again is specified in terms of the allocator-related specification(21.3.3.2 [string.require] p3).

[2020-05-03 Reflector discussion]

Tentatively Resolved by P0408R7 adopted in Cologne 2019.

The change we approved is not what the issue recommended (and not what some implementations do), so we decided with leaving it as Tentatively Resolved to give people a chance to review it.

[2020-11-09 Resolved for C++20. Status changed: Tentatively Resolved → Resolved.]

Rationale:

Resolved by P0408R7.

Proposed resolution: