Re: Revisiting generalized lvalues

[Michael Krasnik <mike at genlogic dot com>]

Andrew Pinski wrote:
> > I don't know if it's too late, but there is yet another reason
> > for the use of generalized lvalues besides just ignorance:
> > using them in macros that verify pointer and struct usage
> > in a large framework. A comma expression makes it very
> > convenient, for example (just a general idea):
> >
> > #ifdef  PRODUCTION
> > #define X_ABC(x)       ( check( x ), x->abc )
> > #else
> > #define X_ABC(x)        x->abc
> > #endif
> >
> > which expands
> >
> >     X_ABC(x) = y;
> >
> > to:
> >
> >     ( check( x ), x->abc ) = y;
> >
> > It is something that is used during development only and
> > is switched off for the production builds. C++ compatibility
> > is not an issue either.
>
>
>
> GCC does this through another extension, like:
> #ifdef CHECKING
> #define CHECK_X(x)   	({const tree __t = x; check(__t); __t; })
> #else
> #define CHECK_X(x)	x
> #endif
> #define X_ABC(x) 	CHECK_X(x)->abc
>
>
> -- Pinski

Your example is a fancier way of rewriting our macros as:

#ifdef  PRODUCTION
#define X_ABC(x)       ( check( x ), &x )->abc
#else
#define X_ABC(x)        x->abc
#endif

to get around the "invalid lvalue" error. It's fine for a
distilled simple example, but quickly becomes ugly for
real multi-level nested macros. Well, I guess we have to
forget about elegance and use the same tricks we do for
other compilers...

Thanks,

/m