tags:

views:

375

answers:

4

Hi, 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();


+4  A: 

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

David Rodríguez - dribeas
Wow... I'll include that snippet to my util... Thanks!
Dony
Too bad I can't upvote you... :(
Dony
you can select a correct answer with the checkmark
fuzzy lollipop
@fuzzy: This post though useful doesn't answer my question.
Dony
+7  A: 

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.

Noah Roberts
Noah Roberts
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<std::ostringstream
sharth
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.
Noah Roberts
+3  A: 

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

AshleysBrain
I am getting hex addresses at the output.
Dony
The workarounds Johannes has suggested seem to work but I am still interested in knowing why what I tried didn't work.
Dony
Josh Townzen
+1  A: 

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;
sharth