Re: GCC's statement expression extension

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> How about, for a start, mandating that the result of a
    Alexandre> statement expression be a POD object?  This would get

Not a bad idea.

    Alexandre> us rid of the problem of handling destructors and would
    Alexandre> be codifying existing practice, since, if my
    Alexandre> understanding is correct, non-PODs get their
    Alexandre> destructors run before the result is made available.
    Alexandre> At the very least, we could issue a warning for this
    Alexandre> case.

There are other problems too:

  #define foo(X) ({ /* some code */ f(X); /* some more code */ })

Now, suppose that X is an expression that creates temporaries, and
that `foo' is a standard library function.  (I've seen this with the
glibc headers by the way.  Some of them do something like:

  #define foo(x) ({ int i = x; ... }) 

which has this form.)

Then, temporaries involved in the X expression are destroyed at the
end of the statement-expression, which is earlier than the language
says they should be.  We break conformant programs in this way.

That's another reason why this construct has such difficult semantics
in C++.  There's really no right answer -- the other answer is to wait
until the end of the enclosing full expression.  But then if you try
to do Per's inlining trick, you find your destructors are run too
late.

The bottom line is that statement-expressions just don't make sense in
C++.  The Scheme analogy (statements are just expressions that happen
to have no value) just doesn't really work because of the impact of
temporaries, destructors, etc.  The Scheme analogy does work much
better in C, and (to reiterate), I don't think statement-expressions
are nearly so problematic in C.

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