Re: Strange behavoiur of ostringstream (tested on g++3.3.5/4.0.2)

[Wladimir Mutel <mwg at mwg dot dp dot ua>]

On Sat, Jan 28, 2006 at 09:34:50AM -0500, Howard Hinnant wrote:

> This is unfortunately standard behavior.  In a nutshell, rvalue  
> streams are ill-supported in C++ today.  When your macro operates on  
> ostringstream() << e, the ostringstream() is an rvalue, and this  
> leads to the behavior you're seeing.

	Very surprising to know about this. My object is on the left of
	expression, it is used as a target for side-effects, but despite
	that it is considered an rvalue.
	"Common pitfalls of C++", I would say :>

> Workarounds:  You could cast your rvalue to an lvalue (say ostream&)  
> before applying the operator <<.

	G++ did not allowed me to do that ("invalid cast of rvalue to
	reference"). VC++ permitted to use a function that takes
	parameter by reference and returns it as the same reference.

> Hope:  I'm fighting tooth and nail to get this behavior changed for C+ 
> +0X, and right now it is looking promising:
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html#Use 
> %20of%20Rvalue%20Streams

	Wish you victory in your fight :>

> This link also contains another workaround that would look like  
> (untested):
> 
> #define SFORMAT(e) ((dynamic_cast<const ostringstream&>(ostringstream 
> ().flush() << e)).str())

	Worked great with G++ ! Thank you !

	I.e. [o]stream should now have special _member_ function that
	returns a reference to is. So far "flush" is acceptable for this
	role as it does not have side-effects on empty stream.

	Looks like a workaround, but now I have to live with it :>