The std::stringstream initialization constructor accepts const string& as a parameter:
explicit stringstream (const string& str,
ios_base::openmode which = ios_base::in | ios_base::out);
This interface was reasonable in C++98, but since C++17 we have std::string_view as a cheaper alternative of the class representing a string. The std::stringstream class doesn't modify the string it accepts, doesn't own it, it doesn't require from it to be null-terminated. So why not to add another constructor overload that accepts the std::string_view? Are there any obstacles that make this solution impossible (or not reasonable) yielding to alternatives like Boost::Iostreams?
At this point (ie: as we approach C++23), there's just not much point to it.
Since you used
stringstreaminstead of one of the more usage-specific versions, there are two possibilities: you either intend to be able to write to the stream, or you don't.If you don't intend to write to the stream, then you don't need the data to be copied. All forms of
stringstreamown the characters it acts on, so you should try to avoid the copy. You can use the C++23 typeispanstream(a replacement for the oldstrstream). This takes aspan<const CharT>, butstring_viewshould be compatible with one ofispanstream's constructors too.If you do intend to write to the stream, then you will need to copy the data into the
stringstream. But you need not perform two copies. So C++20 givesstringstreama move-constructor from astd::string. See constructor #6 here:And since
std::stringis constructable from astring_view, passing astd::string_viewinto astd::stringstreamconstructor will use this move-constructor overload, which should minimize copying.So there's really no need for a
string_view-specific constructor.