Re: GCC standards compliance?
On 7/29/07 8:09 PM, in article o5ari.76605$%k.218522@twister2.libero.it,
"Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> wrote:
Bob ha scritto:
It is not in violation of the standard.
defining macros with the same name as a reserved keyword yields
undefined behaviour.
Could you please post why it would be so? I can't find a reference in
the standard about that. In fact I don't think it is so. Keywords are
converted to tokens in translation phase 7, while macro substitution
happens in phase 4. In a certain sense, keywords do not "exist" yet in
phase 4, while macros do not "exist" any longer in phase 7. So, as long
as the result of macro replacement is a well-formed program, what's
wrong with having a macro with the same name as a keyword?
Redefining a keyword is liable to have strange effects on code that did not
anticipate that the keyword might be redefined. Take the Standard Library
Header files as an example. It would be unreasonable for the Standard to
require that an implementation's Library header files must work correctly
even if the program is redefining C++ keywords left and right. So for this
reason, ?17.4.3.1.1 forbids a translation unit from redefining keywords
whenever a Library header is also included. (Note that in the latest draft
C++ Standard, the prohibition against redefining keywords has become
absolute - but the compiler will have to issue a diagnostic if a program
violates this rule).
According to 2.10, "new" and "delete" are identifiers, but according to
2.12 they are preprocessing-op-or-punc. This ambiguity is the OP's
point. Notice that keywords not listed in 2.12 do not present the same
problem because they are still unconditionally treated as identifiers in
phase 4: "new" and "delete" are special!
Actually, "new" and "delete" are not special (because - just like any other
identifier - either can be #defined as a macro name). The "special" set of
identifiers are those listed in Table 4: "not", "and", "bitand" and friends.
None of these identifiers may be defined as the name of macro name according
to gcc (and on the basis of ?2.11/2, gcc appears to be correct - even though
gcc is the only C++ compiler that I tested for which #defining an
alternative representation identifier as the name of a macro, is an error).
Unfortunately, I'm not a preprocessor expert and I don't know which
interpretation is the correct one... What I know is that every compiler
I ever used happily allow #define new and 1) I don't see anything wrong
with that, 2) it can even be useful. Consider this:
#define new SetDebugInfo(__FILE__, __LINE__) ? 0 : new
I know that there may be contexts where this macro may behaves
strangely, but 99% of the time it does the right thing and I never had
serious problems with it.
Defining a keyword replacement has always seemed to me to be a better
approach for customizing behavior than to redefine the keyword itself. For
example, instead of redefining new as shown in the above example, a program
under development might define (and use) a NEW macro instead:
#define NEW new(__FILE__, __LINE)
Release builds of the same program would then just #define NEW like so:
#define NEW new
In this way the presence of a macro in the program source code is apparent
(and if the macro has not been defined, the compiler reports an error).
Whereas if "new" were the name of the macro, then it is never apparent
whether a "new" that appears in a source file is the keyword or the macro
version. Since either form is likely to compile, no error in the event of a
mix-up is certain to be reported - instead, the behavior of the program when
run, just might not turn out as expected.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]