Disable dynamic allocation in stringstream

[Zereges]

While working in memory restricted environment using custom allocator, I noticed that the following code:

template<typename CharT>
using pmr_stringstream = std::basic_stringstream<CharT, std::char_traits<CharT>, std::pmr::polymorphic_allocator<CharT>>;

std::pmr::memory_resource* get_memory_resource();

int main()
{
    pmr_stringstream<char> sstream(std::ios_base::in | std::ios_base::out, get_memory_resource());
}

Performs a dynamic allocation (via operator new) inside std::ios_base::_Init.

I assume this is not a bug in the STL implementation, as the standard says that the allocator will be used to construct the string in std::basic_­streambuf, but it's not much convenient if I need to have a control over the dynamic allocation in general.

Is there something that can be done to prevent this? Or should I use std::string directly instead?

[StephanTLavavej]

Due to binary compatibility restrictions, we can't change how basic_stringstream uses the provided allocator - so if you need to control dynamic allocation, we recommend using std::basic_string directly (where the provided allocator will be used for all persistent allocations).

[Zereges]

Yeah, I will need to do that, sadly, it doesn't have to convenience of stringstream. Even though there is to_chars available, there is sadly no variant for wchar_t which I need when interacting with some Windows implementation.

[StephanTLavavej]

Consider C++20 <format>, which is capable of formatting arithmetic types to wchar_t (there's a secret wide version of to_chars that it uses, which the Standard has unfortunately not made directly available to users). It has overloads (format_to, etc.) that will write into a provided string, which would use the string's allocator. The formatting machinery avoids unnecessary allocations too - and is much faster than stringstreams (where our old implementation is notoriously slow).

[Zereges]

Learning something new everyday :-), thanks for pointing me to <format>, that's way more convenient than trickery with string::resize, string::data and swprintf

[frederick-vs-ja]

Should this be filed as a vNext issue?