GCC's statement expression extension

Alexandre Oliva aoliva@redhat.com
Sat Jul 29 14:07:00 GMT 2000


On Jul 29, 2000, Mark Mitchell <mark@codesourcery.com> wrote:

> There's really no right answer -- the other answer is to wait
> until the end of the enclosing full expression.

It appears to me that this would solve all of the problems you've
listed so far, and it seems reasonably sound to me.  Is there any
technical reason why we can't do it?  Or that makes it too difficult
to implement in the current C++ framework?

On one hand, I see this solution would be necessary to arrange for
non-POD types to work as arguments to macros.  On the other hand, I
find it troubling that the semantics might be slightly different from
that of an inline function.  But then, if I think of the latter
semantics (of having objects destructed at the end of the
statement-expression, instead of at the end of the full enclosing
statement) in the context of nested statement exceptions, which is not
totally unheard of with so many standard functions implemented as
macros, my head hurts.  It sounds far saner to me, according to the
C++ semantics, to have all temporaries created in it, even if in
nested statement expressions, destructed at the end of the full
statement in which they appear.  It's a pity that this would differ
from the semantics of an inlined function, but then, this has always
been a point in which a macro differs from an inlined function in C++.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me



More information about the Gcc mailing list