Comments on: Where is the sanity in the C++ std library?

By: Luke Wagner

Luke Wagner — Wed, 09 Jul 2008 06:13:36 +0000

That is also odd. It appears that stringstream::str() has been defined to be like fstream::open(): both change the contents of the underlying buffer, and both do not modify the ‘put’ pointer unless the at-end bit is set. Thus, the following gives the desired results:

stringstream ss(ios_base::in | ios_base::out | ios_base::ate);
ss.str(”foo”);

So really, all this confusion has been caused by the fact that ios_base::ate is not a default flag for ostreams. I wonder if there is a good reason not to have it set, because it seems more intuitive.

By: tglek

tglek — Tue, 08 Jul 2008 23:34:03 +0000

Luke,
This seems somewhat reasonable, but as I put in the update, same behavior occurs with stringstream ss;ss.str(”foo”). That doesn’t seem right as there are no more flags to change the behavior

By: Luke Wagner

Luke Wagner — Tue, 08 Jul 2008 23:27:47 +0000

Ah, that is confusing. The issue isn’t with stringstream::str() at all, but with the stringstream constructor. If you run:

stringstream s1(”foo”), s2;
s2 << “foo”;
cout << s1.tellp() << ‘,’ << s2.tellp() << ‘\n’;

you can see the discrepancy: the ‘put’ pointer is being set to the first character by the constructor.

I thought this might be a bug, but 27.7.1.1 explicitly says this is the what should happen *unless* the ios_base::ate (at-end) bit is set in the constructor args. (The default is ios_base::in | ios_base::out). In retrospect, this makes sense because it is the same behavior you would get when you open a fstream for output. Thus, the following constructor call gives you achieves the intended goal of the snippet in the post:

stringstream ss(”foo”, ios_base::in | ios_base::out | ios_base::ate);

By: Nico

Nico — Tue, 08 Jul 2008 20:24:17 +0000

Joe, excellent point. The correct explanation is that stringstream’s constructor does initialize its buffer with the constructor’s argument (”foo”) but does not set the seek position to something else than 0. This is completely independent of str(), and my previous explanation was wrong.

By: tglek

tglek — Tue, 08 Jul 2008 20:21:09 +0000

Nico,
Thank you for the excellent answer. Seems odd that str(string&) doesn’t imply a .seekp, but I’ll live with that now that you’ve uncovered the reason for this mess.

By: Joe

Joe — Tue, 08 Jul 2008 20:11:34 +0000

But Nico,

str() is called after the initial operator<< as well. Shouldn’t that also reset the stream position to the beginning?

By: Nico

Nico — Tue, 08 Jul 2008 19:56:39 +0000

Dear lazyglek,

str() resets the stream position. Add

ss.seekp(0, ios_base::end);

after a call to str() to reset te stream position back to the end: http://codepad.org/TBd4o9aT

By: tglek

tglek — Tue, 08 Jul 2008 19:14:16 +0000

jmdesp,
you suspect wrong

By: jmdesp

jmdesp — Tue, 08 Jul 2008 19:11:28 +0000

I strongly suspect

string s(”foo”);
stringstream ss(s);

would give you the expected behaviour.

Do you see where the difference lies ?

Yes, it would probably make more sense if “ss << “bar”;” did throw an exception in the original version.