views:

320

answers:

8

Hello,

I think the title says pretty much everything, hehe. I would like you to tell me when to use std::istringstream, std::ostringstream and std::stringstream and why I shouldn't just use std::stringstream in every scenario (like are there any runtime performance issues?).

Thanks!

PS: I have a third, less important question. Is there anything bad about this (instead of using a stream at all):

std::string stHehe("Hello ");

stHehe += "stackoverflow.com";
stHehe += "!";
+5  A: 

Personally I find it very rare that I want to preform streaming into and out of the same string stream.

Usually I want to either initialize a stream from a string and then parse it; or stream things too a string stream and then extract the result and store it.

If you're streaming to and from the same stream you have to be very careful with the stream state and stream positions.

Using 'just' istringstream or ostringstream better expresses your intent and gives you some checking against silly mistakes such as accidental use of << vs >>.

There might be some performance improvement but I wouldn't be looking at that first.

There's nothing wrong with what you've written. If you find it doesn't perform well enough then you could profile other approaches, otherwise stick with what's clearest. Personally, I'd just go for:

std::string stHehe( "Hello stackoverflow.com!" );
Charles Bailey
Thank you for you very informative contribution!I started laughing when I saw the very last bit of your answer (the code part) :DOf course the example I posted was not well chosen.
Oliver Baur
A: 

istringstream is for input, ostringstream for output. stringstream is input and output. You can use stringstream pretty much everywhere. However, if you give your object to another user, and it uses operator >> whereas you where waiting a write only object, you will not be happy ;-)

PS: nothing bad about it, just performance issues.

Scharron
+2  A: 

A stringstream is somewhat larger, and might have slightly lower performance -- multiple inheritance can require an adjustment to the vtable pointer. The main difference is (at least in theory) better expressing your intent, and preventing you from accidentally using >> where you intended << (or vice versa). OTOH, the difference is sufficiently small that especially for quick bits of demonstration code and such, I'm lazy and just use stringstream. I can't quite remember the last time I accidentally used << when I intended >>, so to me that bit of safety seems mostly theoretical (especially since if you do make such a mistake, it'll almost always be really obvious almost immediately).

Nothing at all wrong with just using a string, as long as it accomplishes what you want. If you're just putting strings together, it's easy and works fine. If you want to format other kinds of data though, a stringstream will support that, and a string mostly won't.

Jerry Coffin
A: 

Why open a file for read/write access if you only need to read from it, for example?

What if multiple processes needed to read from the same file?

Assaf Lavie
A: 

To answer your third question: No, that's perfectly reasonable. The advantage of using streams is that you can enter any sort of value that's got an operator<< defined, while you can only add strings (either C++ or C) to a std::string.

David Thornley
A: 

Presumably when only insertion or only extraction is appropriate for your operation you could use one of the 'i' or 'o' prefixed versions to exclude the unwanted operation.

If that is not important then you can use the i/o version.

The string concatenation you're showing is perfectly valid. Although concatenation using stringstream is possible that is not the most useful feature of stringstreams, which is to be able to insert and extract POD and abstract data types.

Amardeep
A: 

In most cases, you won't find yourself needing both input and output on the same stringstream, so using std::ostringstream and std::istringstream explicitly makes your intention clear. It also prevents you from accidentally typing the wrong operator (<< vs >>).

When you need to do both operations on the same stream you would obviously use the general purpose version.

Performance issues would be the least of your concerns here, clarity is the main advantage.

Finally there's nothing wrong with using string append as you have to construct pure strings. You just can't use that to combine numbers like you can in languages such as perl.

Mark B
+1  A: 

Others have already handled stringstream vs.[i|o]stringstream well enough; no need for me to go there.

As for std::string -- well, I don't believe that it has << or >> operators, so you couldn't use it where a file stream might be needed. More importantly, though, I'd expect repeated and arbitrary concatenations to a std::string to have O(N**2) performance, or at best O(N*log(N)) performance -- the difference being how careful the programmer is to allocate excess capacity in the target string. However, N concatenations to an ostringstream should have essentially O(N) performance (leaving aside the length of individual strings.) That may be a trivial difference when you're concatenating only one or two strings, and ostringstream may still be slower than std::string when N is small. But I've known cases where N was very large, and the O(N**2) performance really hurt.

Dan Breslau