`<sstream>`: basic_stringbuf C++20 constructors call _Getal()/_Release_to_buffer() breaks user specializations of basic_string

[d-marc]

Command-line test case

#include <sstream>
#include <string>

namespace std {
    template<>
    class basic_string<MyChar> 
    { /* minimal impl */ };
}

// Triggers C2039: '_Getal' is not a member of std::basic_string<MyChar>
std::basic_istringstream<MyChar> s;

With /std:c++20, including and using std::basic_istringstream where std::basic_string is explicitly specialized produces:

C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.44.35207\include\sstream(50): error C2039: "_Getal" ist kein Member von "std::basic_string<MyChar,std::char_traits,std::allocator>".
Siehe Deklaration von "std::basic_string<MyChar,std::char_traits,std::allocator>"

The C++20 constructor basic_stringbuf(basic_string<E,T,A>&&, openmode) calls _Str._Getal() and subsequently _Str._Release_to_buffer(), both of which are MSVC-internal implementation details absent from user specializations. The same code compiles without error in C++17 mode and on GCC/Clang.

Expected behavior

Instantiating std::basic_istringstream<T>, std::basic_ostringstream<T>, or std::basic_stringstream<T> with a user-defined character type T whose std::basic_string<T> is explicitly specialized should compile without errors.

The C++ standard ([namespace.std] p2) permits adding explicit specializations of standard library class templates to namespace std for program-defined types, provided the specialization meets the standard library requirements for the original template. Footnote 140 further states:

"Any library code that instantiates other library templates must be prepared to work adequately with any user-supplied specialization that meets the minimum requirements of this document."

std::basic_stringbuf<T> is standard library code that instantiates std::basic_string<T>. It must therefore work with any conforming user specialization of std::basic_string<T>. The implementation should not require the presence of MSVC-internal methods (_Getal, _Release_to_buffer) that are not part of the std::basic_string interface mandated by the standard and that cannot be present on a user-provided specialization.

STL version

Microsoft (R) C/C++-Optimierungscompiler Version 19.44.35226 für x64

[frederick-vs-ja]

It's continuously happening that library implementations assume all valid specializations of some standard library templates are controlled by the implementations themselves even when the Standard allows program-defined specializations.

See LWG-4509. Also, I don't think it's practical for implementations to make std::erase_if work with flat container adaptors that are user-defined specializations.

[YexuanXiao]

I think fixing this issue would require breaking ABI, or else it would cause performance degradation. This is indeed a flaw and if vNext is released, it should include a fix for this, but not right now.

As far as I can recall, the reason these two functions exist is that std::basic_stringstream (or std::basic_stringbuf) does not actually store a std::basic_string internally, so it cannot satisfy the C++20 requirement that the internal buffer std::basic_string be movable out of a std::basic_stringstream.

However, do you have any reason to specialize std::basic_string? std::basic_string allows custom character types and char_traits because it was invented before Unicode became widely known; the committee now tends not to use them anymore. If you really need to specialize std::basic_string, I would suggest that you provide these two functions when using the STL.

[StephanTLavavej]

That sounds right to me, labeling as vNext. This is a bug although I regard it as a low-priority one (user specializations of Standard types, especially chonkers like basic_string, are rare; this is most commonly seen with the tiny ones like less and hash).

[YexuanXiao]

I just realized it's a duplicate of #938.