33

I use std::stringstream extensively to construct strings and error messages in my application. The stringstreams are usually very short life automatic variables.

Will such usage cause heap reallocation for every variable? Should I switch from temporary to class-member stringstream variable?

In latter case, how can I reserve stringstream buffer? (Should I initialize it with a large enough string or is there a more elegant method?)

Mateen Ulhaq
  • 24,552
  • 19
  • 101
  • 135
jackhab
  • 17,128
  • 37
  • 99
  • 136

4 Answers4

11

Have you profiled your execution, and found them to be a source of slow down?

Consider their usage. Are they mostly for error messages outside the normal flow of your code?

As far as reserving space...

Some implementations probably reserve a small buffer before any allocation takes place for the stringstream. Many implementations of std::string do this.

Another option might be (untested!)

std::string str;
str.reserve(50);
std::stringstream sstr(str);

You might find some more ideas in this gamedev thread.

edit:

Mucking around with the stringstream's rdbuf might also be a solution. This approach is probably Very Easy To Get Wrong though, so please be sure it's absolutely necessary. Definitely not elegant or concise.

luke
  • 36,103
  • 8
  • 58
  • 81
  • 1
    Good advice; however, reserving 50 then copying that string might instead defeat a small non-heap buffer optimization (if your implementation has one). If you want to write your own streambuf, then you have precise control over all buffer management; you'd then use ostream (or istream or iostream, but the question indicates output formatting is the concern here) with your streambuf rather than changing a stringstream's buffer through rdbuf. – Fred Nurk Jan 18 '11 at 05:50
  • 13
    I don't think stringstream reserve anything more than `str`'s content length (which is 0) . According to cplusplus.com: "Constructs a ostringstream object with a copy of str as content.". The reference sais "copy of string content". It doesn't explicitly say that it reserves the same amount of memory. I couldn't find any source that says anything about reserving memory using this constructor. – NickSoft Nov 16 '13 at 11:08
  • The constructor you use above is no longer valid. You can see that the no-copy constructor was removed. http://www.cplusplus.com/reference/sstream/stringstream/stringstream/ – user1122069 Sep 10 '17 at 00:47
  • 2
    You can do it with C++20: std::stringstream sstr(std::move(str)); or avoid a string copy when extracting the result if you are done with the stringstream like this std::move(sstr).str() – lano1106 Dec 02 '21 at 03:56
5

Although "mucking around with the stringstream's rdbuf...is probably Very Easy To Get Wrong", I went ahead and hacked together a proof-of-concept anyway for fun, as it has always bugged me that there is no easy way to reserve storage for stringstream. Again, as @luke said, you are probably better off optimizing what your profiler tells you needs optimizing, so this is just to address "What if I want to do it anyway?".

Instead of mucking around with stringstream's rdbuf, I made my own, which does pretty much the same thing. It implements only the minimum, and uses a string as a buffer. Don't ask me why I called it a VECTOR_output_stream. This is just a quickly-hacked-together thing.

constexpr auto preallocated_size = 256;
auto stream = vector_output_stream(preallocated_size);
stream << "My parrot ate " << 3 << " cookies.";
cout << stream.str() << endl;
Mona the Monad
  • 2,265
  • 3
  • 19
  • 30
4

The Bad

This is an old question, but even as of C++1z/C++2a in Visual Studio 2019, stringstream has no ideal way of reserving a buffer.

The other answers to this question do not work at all and for the following reasons:

  • calling reserve on an empty string yields an empty string, so stringstream constructor doesn't need to allocate to copy the contents of that string.

  • seekp on a stringstream still seems to be undefined behavior and/or does nothing.

The Good

This code segment works as expected, with ss being preallocated with the requested size.

std::string dummy(reserve, '\0');
std::stringstream ss(dummy);
dummy.clear();
dummy.shrink_to_fit();

The code can also be written as a one-liner std::stringstream ss(std::string(reserve, '\0'));.

The Ugly

What really happens in this code segment is the following:

  • dummy is preallocated with the reserve, and the buffer is subsequently filled with null bytes (required for the constructor).
  • stringstream is constructed with dummy. This copies the entire string's contents into an internal buffer, which is preallocated.
  • dummy is then cleared and then erased, freeing up its allocation.

This means that in order to preallocate a stringstream, two allocations, one fill, and one copy takes place. The worst part is that during the expression, twice as much memory is needed for the desired allocation. Yikes!

For most use cases, this might not matter at all and it's OK to take the extra fill and copy hit to have fewer reallocations.

Patrick Cook
  • 41
  • 2
2

I'm not sure, but I suspect that stringbuf of stringstream is tightly related with resulted string. So I suspect that you can use ss.seekp(reserved-1); ss.put('\0'); to reserve reserved amount of bytes inside of underlying string of ss. Actually I'd like to see something like ss.seekp(reserved); ss.trunc();, but there is no trunc() method for streams.

ony
  • 12,457
  • 1
  • 33
  • 41
  • I have tested it in `Visual Studio 2015 Update 3` and seams that raises the `badbit` on. The followed `<<` operators would fail on it. – Andry Oct 11 '18 at 18:25
  • I'm usually don't trust behaviour of MSVC. But as per [`seekp`](https://en.cppreference.com/w/cpp/io/basic_ostream/seekp) and [`seekpos`](https://en.cppreference.com/w/cpp/io/basic_stringbuf/seekpos) I see no requirements to support or not support that operation. Thus you cannot rely that code to be working equally across different compilers+runtimes, I guess. – ony Oct 13 '18 at 08:56