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 withbasic_streambuf()
(30.6.3.1), and initializingmode
withwhich
. Then callsstr(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.
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-onlybasic_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:
Resolved by P0408R7.Proposed resolution: