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: 31.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 31.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(27.4.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:

Proposed resolution: