This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 31.8.4 [ostringstream] Status: NAD Submitter: Markus Kemp Opened: 2014-09-03 Last modified: 2017-03-21
Priority: Not Prioritized
View all other issues in [ostringstream].
View all issues with NAD status.
Discussion:
I initially brought this issue up on Stack Overflow, where I was then told to make a topic about this problem on std-discussion, where I was then in turn asked to report the issue.
The problem: The std::basic_ostringstream class template can be instantiated with an allocator type, but none of the constructors provided accept an allocator argument, which means it's impossible to use std::basic_ostringstream with stateful allocators. The C++ Standard Library Defect Report List seems to already mention a similar issue (2210).[2014-11 Urbana]
Closed as NAD
This is not a rejection of the suggestion, but an observation that simply adding an allocator-aware constructor is only part of the problem. stringstream returns the string assembled in its buffer by value, as the result of a call to str, and typically this will not use the same allocator as would be supplied at construction.
The appropriate way to make progress on this issue, if motivated, is to submit a paper to LEWG addressing the larger design concerns in addition to 'just' adding an (optional) allocator to the constructors.
Proposed resolution: