This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively NAD status.
basic_stringbuf::str()&& should enforce 𝒪(1)Section: 31.8.2.4 [stringbuf.members] Status: Tentatively NAD Submitter: Peter Sommerlad Opened: 2023-10-05 Last modified: 2025-10-24
Priority: 4
View all other issues in [stringbuf.members].
View all issues with Tentatively NAD status.
Discussion:
Recent discussions on llvm-64644
came to the conclusion that basic_stringbuf() && introduced by P0408
might just copy the underlying buffer into a string object and not actually move the allocated space.
While the wording tried to encourage that, especially with the postcondition that the buffer must
be empty afterwards, it failed to specify that the move is never a copy.
𝒪(1) thing.
There might be ABI issues for those who still copy.
Some investigation into 23.2.2.2 [container.reqmts] p.16 and 27.4.3.1 [basic.string.general]
shows that a basic_string as a standard container should move with 𝒪(1).
Unfortunately, we cannot say
str().data() == buf.data()before callingstr()
as a postcondition due to SSO. Maybe a note could be added to eliminate the confusion.
[2025-10-23; Reflector poll; Status changed: New → Tentatively NAD.]
The requirements are already implied, and proposed wording has no effect.
Proposed resolution:
This wording is relative to N4958.
Modify 31.8.2.4 [stringbuf.members] as indicated:
basic_string<charT, traits, Allocator> str() &&;-9- Postconditions: The underlying character sequence
-10- Returns: Abufis empty andpbase(),pptr(),epptr(),eback(),gptr(), andegptr()are initialized as if by callinginit_buf_ptrs()with an emptybuf.basic_string<charT, traits, Allocator>object move constructed from thebasic_stringbuf's underlying character sequence inbuf. This can be achieved by first adjustingbufto have the same content asview(). [Note: — 23.2.2.2 [container.reqmts] require the move construction of the return value to be𝒪(1)end note]