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
