At work, I recently ran across a bug in some legacy code using ostrstream. As it turns out ostrsteam is extremely bug prone. In fact, ostrsteam has actually been deprecated in favor of stringstream. If you’re writing new code, do yourself a favor, stop now, and go use stringstream.
If you can’t - say you’re maintaining legacy code - I strongly advise checking to ensure that your code follows the pattern below. If you’re not - and you’re using dynamic buffering (the default) - you probably have at least one bug and one memory leak in your code.
/* By default the constructor allocates a 512 byte block of memory which is managed by the object itself. */
ostrstream stream;
stream << /* some data */;
/* This is the first bug fix. An ostrstream is a BINARY stream. It is not NULL terminated by default, even when calling str(). Since an allocator is not guaranteed to give you a zeroed block of memory, your string may be much longer then you expect. This could cause memory corruption, data corruption, or stack dumps. (Mine was the first two and was a royal pain in the ass to track down.) */
stream << std::ends;
/* Not absolutely required, but the second parameter is an example of paranoid programming. Just in case someone comments out the line above, you'll still be safe from memory corruption. Note: Depending on you're implementation of string, you might get a string with two null characters at the end. This shouldn't cause any problems, but is worth mentioning for clarity sake. */
std::string str( stream.str(), stream.pcount() );
/* This is the fix for the memory leak. The str() call above gave the caller (you) responsibility for deleting the dynamically created buffer. Rather than worry about how that buffer was allocated (new[] versus malloc), you can just tell ostrstream that you don't have a reference to its internal buffer and it will take ownership of the buffer again. Thus the dynamic buffer gets deleted when stream goes out of scope. */
str.freeze(false);