Is #ifdef MACRO equivalent to a comment
Solution 1
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.
Solution 2
In the general case, both are equivalent.
However, if your "not valid C or C++ code" contains comments, the first form will work, whereas the second won't. That's because C standard forbids imbricated comments.
/* Comments /* inside */ comments are not allowed. */
BTW, #if 0
is often prefered to #ifdef MACRO
in that case.
#if 0
Invalid C source code
#endif
See this question.
Solution 3
Yes, they are equivalent, the preprocessing stage will eliminate Not valid C or C++ code
before the compiler proper sees the code.
Preprocessing involves the removal of comments, and code that is #if
ed out.
But if someone compiles the code with -DMACRO
, the #ifdef
version gets you in trouble, better use #if 0
to remove code via the preprocessor.
Solution 4
The relevant part of the standard is C11 6.10.1 Conditional inclusion /6
:
Each directive’s condition is checked in order. If it evaluates to false (zero), the group that it controls is skipped.
That means, if any of the various forms (if
, ifdef
and so on) evaluate to false, no processing of the group is done and it is totally removed in terms of later stages of processing. It does not get turned into a comment.
user877329
Updated on June 04, 2022Comments
-
user877329 over 1 year
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?
-
Enigma over 10 yearsThere will also be no code in the comment, so I would say yes they are both equal; both empty
-
Elazar over 10 yearsComments are for commenting, macros are for preprocessing-time options. There should be a valid C code inside such macros. at least, valid in certain circumstances. unmatched
/*
should not be there at all,#if
ed out ot not. -
Gui13 over 10 yearsIt is equivalent but not equal. OP is wrong believing that the code will be placed in a comment section. What's really happening is, the code is completely stripped.
-
Elazar over 10 yearsand, if you are worried about unmatched
/*
, then you should be worried about#endif
s in the middle of the "invalid C source code". -
paxdiablo over 10 yearsWow, I had to actually go look up imbricate. That doesn't happen very often :-)
-
gx_ over 10 yearsYou won't even have the
// before
and// after
comments remaining, because comments are stripped out before the preprocessing phase. -
leemes over 10 yearsActually this is not true. Comments get removed by the preprocessor, too.
-
user877329 over 10 yearsThe MACRO way gives me a possibility to check if the block is interesting to me. Actually I will __MACRO__ to get into reserved namespace.
-
md5 over 10 years@Elazar:
#ifdef/#endif
directives can be imbricated, but comments cannot. I am not refering to "unmatched/*
, since it doesn't work with matched/*
neither. -
leemes over 10 years@gx_ You mean before the preprocessing directives phase, i.e. before processing macros and #ifs. But both phases are considered part of the preprocessor.
-
gx_ over 10 years@leemes Thank you for the correction. That is indeed what I meant (sorry...)