What is the possible use for “#define for if (false) {} else for”?

by

It’s to fix a bug in old versions of Visual C++ (v6.0 and earlier). In the past, Visual C++ had broken scope rules about variables declared inside for statements:

// This compiles in old versions of Visual C++, but it is in fact INVALID C++
for(int i = 0; ...)
{
    ...
}

for(i = 0; ...)
{

}

In other words, Visual C++ gives i a scope as if it were declared outside the loop, and it lets you continue using it after the loop is done. This lead to code such as the above snippet. In more standards-compliant compilers, i is no longer in scope at the definition of the second for loop, so the compiler issues an error about i being undefined.

To fix this, some people used this macro (or very similar, equivalent macros):

#define for if(0) {} else for

This changes the for loop into this:

if(0)
{
}
else
    for(int i = 0; ...)
    {
        ...
    }

This puts the for loop into an extra level of scope, so that any variables declared in the for loop will be out of scope afterwards, regardless of Visual C++’s bug. This makes sure that the same code compiles correctly consistently in both Visual C++ and standards-compliant compilers, and that incorrect code does not compile correctly consistently.

Also note that if the macro were instead defined as so:

// DO NOT USE
#define for if(1) for

Then although that would have the same effect for some simple code, it would suddenly cause the following code to be compiled incorrectly:

if(foo)
    for(...)
    {
        ...
    }
else
    doSomething();

Because if you expand the macro, you get this:

if(foo)
    if(1)
        for(...)
        {
            ...
        }
    else
        doSomething();

And the else now matches up with the wrong if! So, the clever use of using if(0) {} else instead of if(1) avoids this problem.

As a final note, #define for if(0) {} else for does not cause infinite recursion, because the preprocessor will not recursively replace the macro which you are currently defining. It will only do one replacement in this case.

More Related Contents:

  1. The need for parentheses in macros in C [duplicate]
  2. #define macro for debug printing in C?
  3. #pragma pack effect
  4. Real-world use of X-Macros
  5. Easy way to use variables of enum types as string in C?
  6. MIN and MAX in C
  7. How do I check OS with a preprocessor directive?
  8. What are the applications of the ## preprocessor operator and gotchas to consider?
  9. Stringification of a macro value
  10. What is the meaning of lines starting with a hash sign and number like ‘# 1 “a.c”‘ in the gcc preprocessor output?
  11. Are typedef and #define the same in c?
  12. Macro vs Function in C
  13. How to compare strings in C conditional preprocessor-directives
  14. Understanding container_of macro in the Linux kernel
  15. What are the valid characters for macro names?
  16. Does the C preprocessor strip comments or expand macros first? [duplicate]
  17. What does ## mean for the C(C++) preprocessor?
  18. Finding out what the GCC include path is [duplicate]
  19. Variadic macro trick
  20. Type of #define variables
  21. How to use #if inside #define in the C preprocessor?
  22. #ifdef inside #define
  23. Is there a good reason for always enclosing a define in parentheses in C?
  24. Detecting Endianness
  25. C preprocessor: expand macro in a #warning
  26. C circular dependency
  27. What is a good reference documenting patterns of use of X-Macros in C (or possibly C++)?
  28. Should variable definition be in header files?
  29. offsetof at compile time
  30. Using Parentheses in Define Preprocessor Statements

Leave a Comment