This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bad macro definition: gettext


Troy A. Griffitts wrote:-

> >Whether something is or is not a macro is nothing to do with
> >GCC; it's the package concerned.
> 
> Ok, is there a glibc list or something to which I should post this?

I imagine it's glibc, yes.

> >You can do either a #undef or put parentheses around gettext to
> >avoid the macro expansion.
> 
> Thanks, I never knew about this.
> 
> so, myClass->(gettext)(...)
> 
> ???

Yes.  It's just an expression like any other, and so can be
parenthesized.  The standards require a function-like macro to be
have '(' as the next token for it to be expanded.

> >If you're including gettext headers,
> >it's really your responsibility to avoid names that are in those
> >headers or avoid assumptions about their form (in the case of
> >function names).
> 
> Actually, that's kindof lame to tell a C++ programmer.  First of all, 
> macros, should almost never be used in C++, and second of all you are 
> saying that ::globalFunction is NEVER safe, as someone might choose to 
> define that global function as a macro, and your scoped impl will be hosed.

The underlying package is C-based I'm sure.  That's the way macros work
in C and C++; they have no notion of lexical scope.  Arguably it's lame
for the package to make gettext a macro, yes.

Neil.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]