Created on 2023-10-05.00:00:00 last changed 1 month ago
This wording is relative to N4958.
Modify [stringbuf.members] as indicated:
basic_string<charT, traits, Allocator> str() &&;
-9- Postconditions: The underlying character sequence buf is empty and pbase(), pptr(), epptr(), eback(), gptr(), and egptr() are initialized as if by calling init_buf_ptrs() with an empty buf.-10- Returns: A basic_string<charT, traits, Allocator> object move constructed from the basic_stringbuf's underlying character sequence in buf. This can be achieved by first adjusting buf to have the same content as view().
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.I suggest to amend the specification to enforce implementors to do the 𝒪(1) thing. There might be ABI issues for those who still copy. Some investigation into [container.reqmts] p.16 and [basic.string.general] shows that a basic_string as a standard container should move with 𝒪(1). Unfortunately, we cannot say
as a postcondition due to SSO. Maybe a note could be added to eliminate the confusion.
|2023-10-14 13:40:27||admin||set||messages: + msg13751|