c++ std::stringstream - Why was std::strstream deprecated?




example include (5)

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.

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?


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.


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


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.


In the same line (I think this was not highlighted by any answer) it's good to mention that sometimes (specially in software where the performance matters—like in the Linux kernel) you can find some if statements like the following:

if (likely( everything_is_ok ))
{
    /* Do something */
}

or similarly:

if (unlikely(very_improbable_condition))
{
    /* Do something */    
}

Both likely() and unlikely() are in fact macros that are defined by using something like the GCC's __builtin_expect to help the compiler insert prediction code to favour the condition taking into account the information provided by the user. GCC supports other builtins that could change the behavior of the running program or emit low level instructions like clearing the cache, etc. See this documentation that goes through the available GCC's builtins.

Normally this kind of optimizations are mainly found in hard-real time applications or embedded systems where execution time matters and it's critical. For example, if you are checking for some error condition that only happens 1/10000000 times, then why not inform the compiler about this? This way, by default, the branch prediction would assume that the condition is false.





c++ stringstream strstream