83

I recently discovered that std::strstream has been deprecated in favor of std::stringstream. It's been a while since I've used it, but it did what I needed to do at the time, so was surprised to hear of its deprecation.

My question is why was this decision made, and what benefits does std::stringstream provide that are absent from std::strstream?

andand
  • 17,134
  • 11
  • 53
  • 79
  • @Chris Lively: You're saying that it was just a naming convention issue, or are you just joking? – andand May 12 '10 at 15:24
  • I don't know for sure, but this URL found via Google might help: http://bytes.com/topic/c/answers/158338-strstream-depreciation – Will Bickford May 12 '10 at 15:24
  • 1
    @andand check Exceptional C++, it's nicely explained there. – There is nothing we can do May 12 '10 at 15:26
  • @andand: It was a joke. ;) I believe Ken below has the right answer – NotMe May 12 '10 at 15:44
  • 1
    @Christ Lively: Thanks for the clarification. I thought you were probably joking, but it's hard to tell sometimes. – andand May 12 '10 at 15:47
  • Almost 4 years late, but I want to add, that `strstream` has been deprecated in EVERY standard, it still perplexes me why they were ever added to the standard… – MFH Feb 21 '14 at 22:31
  • @Will Bickford. Thx for the link. It exactly specifies my intended use case being a stream view on an external string resource. stringstreams are much safer but they copy the string and allocate a buffer which can be a performance thing when you do this 50k times. – gast128 Jun 30 '20 at 09:22

4 Answers4

103

The strstream returned a char * that was very difficult to manage, as nowhere was it stated how it had been allocated. It was thus impossible to know if you should delete it or call free() on it or do something else entirely. About the only really satisfactory way to deallocate it was to hand it back to the strstream via the freeze() function. This was sufficiently non-obvious, that lots of people got it wrong. The stringstream returns a string object which manages itself, which is far less error prone.

There was also the issue of having to use ends to terminate the string, but I believe the deallocation problem was the main reason for deprecation.

Dan Nissenbaum
  • 13,558
  • 21
  • 105
  • 181
  • 2
    a friend-lock guard accessor would have solved this problem without making copies of copies of data which is the current solution. { std::bufferguard f(mystream); printf("%s\n", f.str()); } – Erik Aronesty Apr 28 '15 at 19:27
  • lol people used strstream only because they wanted to have control of the memory maangement – Martin Kosicky Mar 07 '19 at 06:11
  • I don't think ```std::stringstream``` is ever a perfect replacement for ```std::strstream```. ```std::strstream``` can do some things better than ```std::stringstream```. Fortunately, we will have ```std::spanstream``` in C++23 – frozenca Jul 23 '22 at 13:42
17

Easier to understand memory management. (Can someone remember who is responsible for freeing the allocated memory and in which conditions?)

(Note that as strstream still provide something which is not available elsewhere, it will continue to be present in C++0X -- at least last time I checked the draft it was).

AProgrammer
  • 51,233
  • 8
  • 91
  • 143
  • 5
    If you provide the buffer, you are responsible for freeing it. If it provided the buffer, it will free it, but you have to remember to unfreeze the stream or it won't. `c_str = stream.str(); /*use c_str*/ stream.freeze(false);` – Dennis Zickefoose May 12 '10 at 15:53
12

A strstream builds a char *. A std::stringstream builds a std::string. I suppose strstreams are deprecated becuase of the potential for a buffer overflow, something that std::string automatically prevents.

Ken Bloom
  • 57,498
  • 14
  • 111
  • 168
  • strstream doesn't actually build the char * ... it just sticks a null on the end of the buffer it internally allocated. the issue was the weird accessor "freeze" ... which should have been implemented as a guard. – Erik Aronesty Apr 28 '15 at 19:28
7

From a personal perspective on more than one occasion I've seen obscure memory corruptions that took days or weeks to track down and eventually came down to use of strstream. As soon as it was replaced with stringstream the corruptions vanished and I didn't ask any more questions! That was enough for me.

Component 10
  • 10,247
  • 7
  • 47
  • 64