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

Question

In another question, I just spotted this little pearl of C wisom:

#define for if (false) {} else for

which caused MSVC to spit out "constant expression" warnings for a quite valid statement:

for (int i = 0; i <= 10; i++) {...}

I understand why MSVC is complaining because it expands to:

if (false) {} else for (int i = 0; i <= 10; i++) {...}

I just don't understand why the developers would use that little snippet. Anyone got a clue stick they can beat me with?

Answer 1

According to a quick search it's a bug in MSVC that gets overcame.

As I understand it,

for(int i=0...){.....} 
//later at the same scope level in the same function
for(int i=0...){...}

will cause a redefinition of 'i' error.

If the for statement is enclosed in an if statement, the compiler works as it should so that there is no redefinition error(apparently it interprets scope levels of 'if' but not 'for')

Answer 2

It's to fix a bug in old versions of Visual Studio. In the past, Visual Studio had broken scope rules about variables declared inside for statements:

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

for(i = 0; ...)
{

}

In other words, Visual Studio 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 Studio's bug. This makes sure that the same code compiles correctly consistently in both Visual Studio 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.

Answer 3

The effect was already described.

The reason to have it is to port C++ code to MSVC. Or it is also very helpfull if you want your C++ code platformindependent. For example, you developed it on Linux/MacOSX and now want to compile it in MSVC.

And it is also very usefull for C++ itself. For example:

for(std::set<Foo>::iterator i = myset.begin(); i != myset.end(); ++i) {
    // ...
}

for(int i = 0; i < N; ++i) {
    // ...
}

I have seen MSVC code which worked around this by doing either:

for(std::set<Foo>::iterator i1 = myset.begin(); i1 != myset.end(); ++i1) {
    // ...
}

for(int i2 = 0; i2 < N; ++i2) {
    // ...
}

Or:

{for(std::set<Foo>::iterator i = myset.begin(); i != myset.end(); ++i) {
    // ...
}}

{for(int i = 0; i < N; ++i) {
    // ...
}}

In both cases (imo) not that nice. And this #define is a small hack to make MSVC behave more standard.