Re: GCC standards compliance?
Greg Herlihy ha scritto:
"Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> wrote:
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).
Ah! Clause 17 is the last place where I would have looked for such
requirement. Although I acknowledge the intent, the wording in
17.4.3.1.1 paragraph 2 of the draft bothers me. Why did they put a
blanket requirement affecting any C++ program in the introductory clause
to the standard library? Clause 16.3 [cpp.replace] seems a much better
place to me. Moreover, I think the requirement is much stricter than
needed: if I first include a library header and then define "new" as a
macro, the interpretation of the library header won't be affected in any
way...
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).
So you are saying that the fact that "new" and "delete" are listed as
preprocessing-op-or-punc does not prevent them to also be identifiers?
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
This definition has two serious drawbacks, however:
1) you lose the ability to use in-place new, i.e.: you can't write
"NEW(something) T" as it won't compile in debug mode;
2) you need to provide a two-parameter operator new both globally and
for every class that overloads operator new.
About the name, I agree that using "NEW" instead of "new" may be
prettier, but you have to consider that by redefining the keyword "new"
you are de facto mandating the use of the redefinition, while by using
"NEW" there will always be someone in your team forgetting to use the
right name ;-)
Just my opinion,
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]