Is #ifdef MACRO equivalent to a comment

12,721

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 #ifed 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.

Share:
12,721
user877329
Author by

user877329

Updated on June 04, 2022

Comments

  • user877329
    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
    Enigma over 10 years
    There will also be no code in the comment, so I would say yes they are both equal; both empty
  • Elazar
    Elazar over 10 years
    Comments 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, #ifed out ot not.
  • Gui13
    Gui13 over 10 years
    It 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
    Elazar over 10 years
    and, if you are worried about unmatched /*, then you should be worried about #endifs in the middle of the "invalid C source code".
  • paxdiablo
    paxdiablo over 10 years
    Wow, I had to actually go look up imbricate. That doesn't happen very often :-)
  • gx_
    gx_ over 10 years
    You won't even have the // before and // after comments remaining, because comments are stripped out before the preprocessing phase.
  • leemes
    leemes over 10 years
    Actually this is not true. Comments get removed by the preprocessor, too.
  • user877329
    user877329 over 10 years
    The 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
    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
    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_
    gx_ over 10 years
    @leemes Thank you for the correction. That is indeed what I meant (sorry...)