Why was std::strstream deprecated?

Question

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?

Apogeotropism

I don't know for sure, but this URL found via Google might help: bytes.com/topic/c/answers/158338-strstream-depreciation – Poultice

@Apogeotropism check Exceptional C++, it's nicely explained there. – Referee

@andand: It was a joke. ;) I believe Ken below has the right answer – Imagism

@Christ Lively: Thanks for the clarification. I thought you were probably joking, but it's hard to tell sometimes. – Apogeotropism

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… – Overprint

@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. – Flagellant

Answer 1

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.

Perigee

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()); } – Knar

lol people used strstream only because they wanted to have control of the memory maangement – Farley

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 – Belvia

Answer 2

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).

Volgograd

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); – Galvani

Answer 3

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.

Devlin

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. – Knar

Answer 4

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.

Duma