Re: GCC's statement expression extension

[Mark Mitchell <mark at codesourcery dot com>]

Jamie --

  Thanks for your example.

  I've checked in the attached patch, using your example.  I've tried
to explain things so that both library designers and C++ users can
understand the issues.  Updates and clarifications are certainly
welcome.

  Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

2000-08-03  Mark Mitchell  <mark@codesourcery.com>

	* extend.texi: Add commentary on statement-expressions and their
	interactions with C++.

Index: extend.texi
===================================================================
RCS file: /cvs/gcc/egcs/gcc/extend.texi,v
retrieving revision 1.58
diff -c -p -r1.58 extend.texi
*** extend.texi	2000/07/28 13:24:20	1.58
--- extend.texi	2000/08/03 23:06:26
*************** If you don't know the type of the operan
*** 184,189 ****
--- 184,232 ----
  must use @code{typeof} (@pxref{Typeof}) or type naming (@pxref{Naming
  Types}).
  
+ Statement expressions are not supported fully in G++, and their fate
+ there is unclear.  (It is possible that they will become fully supported
+ at some point, or that they will be deprecated, or that the bugs that
+ are present will continue to exist indefinitely.)  Presently, statement
+ expressions do not work well as default arguments. 
+ 
+ In addition, there are semantic issues with statement-expressions in
+ C++.  If you try to use statement-expressions instead of inline
+ functions in C++, you may be surprised at the way object destruction is
+ handled.  For example:
+ 
+ @example
+ #define foo(a)  (@{int b = (a); b + 3; @})
+ @end example
+ 
+ @noindent
+ does not work the same way as:
+ 
+ @example
+ inline int foo(a) @{ int b = a; return b + 3; @}
+ @end example
+ 
+ @noindent
+ In particular, if the expression passed into @code{foo} involves the
+ creation of temporaries, the destructors for those temporaries will be
+ run earlier in the case of the macro than in the case of the function.
+ 
+ These considerations mean that it is probably a bad idea to use
+ statement-expressions of this form in header files that are designed to
+ work with C++.  Note that the GNU C Library does contain header files
+ using statement-expressions, and that these definitions make the library
+ technically non-conforming.  For example, when optimization is turned
+ on,
+ 
+ @example
+ string a, b;
+ printf("%s", toupper((a+b).c_str()[0]));
+ @end example
+ 
+ @noindent
+ will result in the destructor for the temporary created for @code{a+b}
+ being run earlier than it should be.
+ 
  @node Local Labels
  @section Locally Declared Labels
  @cindex local labels