Re: GCC standards compliance?
Bob ha scritto:
borophyll@gmail.com wrote:
GCC allows you to define macros called "new" and "delete" in the
preprocessor phase. This seems to be in violation of the C++ spec, in
particular the rules for the creation of preprocessing tokens.
Section 2.4 of ISO/IEC 14882:2003 states that preprocessing tokens
belong to one of the following groups
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?
Anyway, correct or incorrect, your answer is IMHO totally missing the
OP's point. The standard says that a #define directive has one of the
two forms (clause 16, para 1):
# define identifier replacement-list new-line
# define identifier lparen identifier-listopt ) replacement-list new-line
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!
2.4/2 lists the preprocessor token categories and doesn't say whether
the categories are mutually exclusive. So we have two different possible
interpretation: either the categories are mutually exclusive or not.
If the categories are not mutually exclusive: new and delete are *both*
identifiers and preprocessing-op-or-punc. In this case
#define new something
is acceptable (in phase 4! what is the effect in phase 7 is another
story and is not relevant here).
On the other hand, if the categories are mutually exclusive, 2.12
overrules 2.10 and "new" and "delete" are *not* identifier. In this case
#define new something
is ill-formed right in phase 4. It's not undefined behaviour and we
don't even need to wait till phase 7 to say that! It would be the same
as writing:
#define == something
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.
Just my two eurocent,
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]