This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC's statement expression extension
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Subject: Re: GCC's statement expression extension
- From: Gabriel Dos Reis <gdr at codesourcery dot coom>
- Date: 27 Jul 2000 13:53:43 +0200
- Cc: Mark Mitchell <mark at codesourcery dot com>, rth at cygnus dot com, law at cygnus dot com, gcc at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <Pine.SOL.4.21.0007271228330.13641-100000@red.csi.cam.ac.uk>
"Joseph S. Myers" <jsm28@cam.ac.uk> writes:
| On Wed, 26 Jul 2000, Mark Mitchell wrote:
|
| > (Actually, I bet you can write those functions with only __typeof__
| > and not statement-expressions:
| >
| > # define __TGMATH_UNARY_REAL_ONLY(Val, Fct) \
|
| Actually I've concluded on examining the specification of the <tgmath.h>
| macros that glibc's versions are broken and the GCC's current facilities
| don't seem to be sufficient to implement them anyway. More on this later.
| (Quite how the standards committee thought the type-generic macros fitted
| in with the spirit of C, I don't know.)
Well, if you come up with a good understanding of how that should be done,
please ping me: I'm curious about how the C committee thought <tgmath.h>
could be implemented.
| > Does that do the trick? The __typeof__ extension is far less
| > problematic than statement-expressions -- although even __typeof__ has
| > serious issues in C++, where the type of an expression can depend on
| > its context.)
|
| Perhaps these facilities can be deprecated / removed first in the C++
| compiler.
That seems to me to be good step.
-- Gaby
CodeSourcery, LLC http://www.codesourcery.com