Assuming that MACRO is not defined, are these equivalent
#ifdef MACRO
Not valid C or C++ code
#endif
/*
Not valid C or C++ code
*/
In GCC 4.7.1, it seems to be equivalent but are there preprocessors that do more?
It depends on what you mean by "not valid C or C++ code".
Text inside a comment does not have to conform to most of the rules of the language. It isn’t even tokenized. This is perfectly valid:
/* This comment doesn't contain a valid sequence of preprocessing tokens
(because of the apostrophe). */
The only rules it does have to obey are the ones that control where the comment ends. People regularly get tripped up by backslash-newline in line comments (in fact, SO's syntax highlighter used to get this wrong!)
// Line comment with ascii art ending with a \
Oops! This line is commented out too!
and less often (if only because every C tutorial warns you about this) by block comments not nesting:
/* you can't nest /* block comments */ these words are not commented */
On the other hand, text inside a "skipped" preprocessor conditional "group" does have to conform to some of the rules of the language. The exact words of the standard (C99 §6.10.1p5) are
Each directive’s condition is checked in order. If it evaluates to false (zero), the group that it controls is skipped: directives are processed only through the name that determines the directive in order to keep track of the level of nested conditionals; the rest of the directives’ preprocessing tokens are ignored, as are the other preprocessing tokens in the group.
There are two important bits. First, the text is tokenized, so it does have to be a valid sequence of preprocessing tokens.
#if 0
This skipped conditional group doesn't contain a valid sequence of
preprocessing tokens (because of the apostrophe).
#endif
is a syntax error.
$ gcc -fsyntax-only test.c
test.c:2:37: warning: missing terminating ' character
this skipped conditional group doesn't contain a valid sequence of
^
Second, directives are still partially processed "in order to keep track of the level of nested conditionals", which means you can do this:
#if 0 // forget this entire mess
#ifdef __linux__
do_linux_specific_thing();
#elif defined __APPLE__
do_osx_specific_thing();
#elif defined _WIN32
do_windows_specific_thing();
#endif
#endif
and you can’t do this:
#ifdef __linux__
do_linux_specific_thing();
#elif defined __APPLE__
do_osx_specific_thing();
#if 0 // forget windows
#elif defined _WIN32
do_windows_specific_thing();
#endif
#endif
(You won’t get an error for that last, but…
$ gcc -E -P -U__linux__ -D__APPLE__ -D_WIN32 test.c
do_osx_specific_thing();
do_windows_specific_thing();
… I don’t think that’s what whoever wrote it meant it to do.)
Many guides to the language tell you to use #if 0 to "comment out" large regions of code that you want to disable temporarily. They say this because block comments don‘t nest. If you try to disable a region of code with a block comment, but there’s a block comment inside that region, the commenting-out will end prematurely and probably the code will fail to compile. This was more important in the days when C didn’t have line comments; some projects use only line comments for commentary, reserving block comments for disabling code.
But because code inside #if 0 … #endif is still tokenized, and nested preprocessor conditionals must still balance, you do have to be a little careful about where you put the #if 0 and the #endif. It’s usually not a problem, because the code used to compile before you disabled it, so it shouldn’t have anything in it to cause a tokenization error.