Problem with std::ostringstream

Question

I tried to make the code #1 more terse by changing it to code #2 but it doesn't work as expected. Can anyone please tell me why it doesn't work? Thanks.

Code #1

double x = 8.9, y = 3.4, z = -4.5;
std::ostringstream q0;
q0 << "(" << x << "," << y << "," << z << ")";
std::string s = q0.str();

Code #2

double x = 8.9, y = 3.4, z = -4.5;
std::string s = static_cast<std::ostringstream &>(
  std::ostringstream() << "(" << x << "," << y << "," << z << ")").str();

@Dony: What is the result you want and what is actually happening? — Felix Kling, Mar 29 '10 at 16:06
@Felix: I want `(8.9,3.4,-4.5)` as output. But I am getting some garbage at output. — Dony, Mar 29 '10 at 16:07
Because they thought that the question is unclear or not useful. One reason why they might have considered that the question is unclear is the fact that you did not describe the behaviour of your program at all, so it was not clear what you wanted it to do. Also, the question title is far from descriptive. — Daniel Daranas, Mar 29 '10 at 16:11
@The Elite Gentleman: Jon Skeet is not a C++ expert by any stretch. http://stackoverflow.com/search?q=user:22656+[c%2b%2b] — Michael Myers, Mar 29 '10 at 16:13
@fuzzy: IMO if the terse version is equally understandable, it's okay to use it. — Dony, Mar 29 '10 at 17:01
@mmyers, I was being sarcastic. I didn't point to his profile but to a search engine that uses Jon Skeet's name. — Buhake Sindi, Mar 29 '10 at 17:03
@The: OK, I haven't seen it in quite a while and thought it searched his posts by default. Never mind then. — Michael Myers, Mar 29 '10 at 17:16
@Dony: AshleysBrain's answer already gave you a link to a duplicate question, and there are a couple of good answers to that question that explain what's happening. — Josh Townzen, Mar 31 '10 at 20:23

Edward Strange · Answer 1 · 2010-03-29T16:22:34.373

7

I've reproduced your garbage. The only thing I can think of is that your static cast is invalid. That seems really odd to me but it's the only thing I can think might be happening. It could be that op<< returns something other than ostringstream that is not castable to ostringstream...like a reference stream of some sort. In fact, when assigning the reference to a variable and looking at the type in a debugger, it looks weird for a ostringstream.

At any rate, there's no reason to be "terse". In fact, being terse is often quite annoying to other developers who have to read your code. If you want to be "terse", put you stream stuff in a function that returns a string and name it something useful.

Edit:

Actually, I think I may have a better answer. You're binding a non-const reference to a temporary and calling a function on it. A const reference is guaranteed to continue existing until the end of the 'statement' (forgetting the technical term right now but it's close). A non-const reference does not have this guarantee. Therefore I think you are eliciting undefined behavior when you call str() on this non-const reference because the compiler is free to delete the temporary it refers to.

edited Mar 29 '10 at 16:22

answered Mar 29 '10 at 16:15

Edward Strange

40,307
7
73
125

I don't think either of these answers is correct. I tried dynamic_cast and it did not throw or change output. I tried const& and it also did not alter anything. Don't know what you're running into, could simply be a compiler bug. My advice stands though. – Edward Strange Mar 29 '10 at 16:53
The temporary being optimized away would make sense to me. If you do the code below and allocate on the heap and do a memory leak, you don't have the error. std::string s = static_cast(*(new std::ostringstream()) << "(" << x << "," << y << "," << z << ")").str(); – Bill Lynch Mar 30 '10 at 04:04
You could be right but after looking up the rules for temporary lifetimes I don't believe the compiler is free to do that. Optimizing something away is not supposed to change well defined behavior. If, as I believe is true, the statement is well defined then this would be a compiler bug. – Edward Strange Mar 30 '10 at 19:29
The temporary lifetime is up to the end of the full expression, which in this case is the semicolon and *after* the string has been copied. There is no lifetime issues in the code. – David Rodríguez - dribeas Dec 12 '12 at 20:24

score 3 · Answer 2 · edited May 23 '17 at 12:18

3

You may want to use the code provided in this answer.

edited May 23 '17 at 12:18

Community

1
1

answered Mar 29 '10 at 16:13

David Rodríguez - dribeas

204,818
23
294
489

Wow... I'll include that snippet to my util... Thanks! – Dony Mar 29 '10 at 16:21
@fuzzy: This post though useful doesn't answer my question. – Dony Mar 29 '10 at 17:01

score 3 · Answer 3 · edited May 23 '17 at 10:33

3

I asked a similar question a while ago. The answers explain why what you've done doesn't work (you might have encountered either compile-time errors or printing strings as hex addresses like I did), and how to get around it (Johannes Schaub posted a very nice workaround using getlval()).

edited May 23 '17 at 10:33

Community

1
1

answered Mar 29 '10 at 16:48

AshleysBrain

22,335
15
88
124

I am getting hex addresses at the output. – Dony Mar 29 '10 at 17:02
The workarounds Johannes has suggested seem to work but I am still interested in knowing why what I tried didn't work. – Dony Mar 29 '10 at 17:03
@Dony: Tronic's answer to AshleysBrain's question, and especially Tronic's comment below his answer, give more details as to why your code isn't working. It can't pass the temporary `ostringstream` to `ostream &operator<<(ostream &, char const *)`, since you can't bind a temporary to a non-const reference. However, it can pass the `ostringstream` to `ostream &ostream::operator<<(void const *)`, since that function is a member function and it's legal to call a member function of a temporary variable. The `void const *` version of the function prints the pointer as a hex value. – Josh Townzen Mar 30 '10 at 05:49

score 1 · Answer 4 · answered Mar 30 '10 at 04:08

1

If you have access to the boost format library, the following could be considered more "terse".

cout << boost::format("writing %1%,  x=%2% : %3%-th try") % "toto" % 40.23 % 50;

answered Mar 30 '10 at 04:08

Bill Lynch

80,138
16
128
173

score 1 · Answer 5 · edited Nov 08 '12 at 14:43

1

You have the answer as to "why" above which has been addressed.

A quick suggestion is that you can always make your thing work by substituting ostringstream() with ostringstream().flush(). That makes the result eligible for ref-to-non-const binding.

edited Nov 08 '12 at 14:43

Gilles 'SO- stop being evil'

104,111
38
209
254

answered Oct 25 '11 at 16:45

igorlord

376
3
4

for prosperity, you should include the answer as you mentioned in your own post. – Inbar Rose Nov 08 '12 at 14:41
This seems to more like a comment than answer. – Starx Nov 08 '12 at 14:41

score 0 · Answer 6 · answered May 11 '11 at 12:14

Some of the ostream operator<< overloads — in particular those for std::string and char const* are free functions, like:

ostream& operator<<(ostream& os, T const&);

If the stream is a temporary (which in your case it is), it cannot bind to that ref-to-non-const, and the overload cannot be chosen.

So you are instead accidentally using a non-preferred overload by accident; in this case, the overload for void const*. That's why you're seeing pointer contents (it's not "garbage").

This is a limitation when trying to do this serialisation on a single line, and you can't get around it.

Problem with std::ostringstream

6 Answers6