BOOL / bool issues

In windef.h you can find the following type:

typedef int BOOL;

This is used here and there instead of the standard bool type. As far as I know, this was for performance reasons. The following function, for example, suffers from a performance warning in VC++:

bool TestFlagBool(int n, int flags)

{

// warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)

return flags & (1<<n);

}

It compiles to the following code:

004010B0 mov ecx,dword ptr [esp+4]

004010B4 mov eax,1

004010B9 shl eax,cl

004010BB test dword ptr [esp+8],eax

004010BF setne al

004010C2 ret

A common way to remove the warning is to explicitly cast the result to a boolean value:

bool TestFlagBool(int n, int flags)

{

return (flags & (1<<n))!=0;

}

This does not make the code faster, it only tells the compiler we know about the cast, and we know about its price. This compiles to the following code:

004010B0 mov ecx,dword ptr [esp+4]

004010B4 mov eax,1

004010B9 shl eax,cl

004010BB and eax,dword ptr [esp+8]

004010BF neg eax

004010C1 sbb eax,eax

004010C3 neg eax

004010C5 ret

Now, using a BOOL (i.e. an int in disguise) gets rid of the cast entirely. No cast, no warning:

BOOL TestFlagInt(int n, int flags)

{

return flags & (1<<n);

}

This new function gives birth to the following code:

004010D0 mov ecx,dword ptr [esp+4]

004010D4 mov eax,1

004010D9 shl eax,cl

004010DB and eax,dword ptr [esp+8]

004010DF ret

The good thing is that it is now faster than the two previous versions. The bad thing is that it can produce unexpected bugs, if you don’t pay attention. The original code indeed, only returned true or false, i.e. exactly 1 or 0. The new code however, returns zero or non-zero, but you do not have any guarantee that the non-zero value is 1. As a result, the following functions do not return the same results:

int Flags = 2;

if(TestFlagBool(1, Flags)==true)

{

// Goes there

}

if(TestFlagInt(1, Flags)==true)

{

// Doesn’t go there

}

This is quite normal if you think about it: TestFlagInt returns 2, which is not equal to “true”, i.e. 1. Hence the failure. Note that using TRUE (capital version, the Windows counterpart to true, also defined in windef.h) does not help, it still fails the same way. The only safe way to make sure the code is solid against that kind of issues is to use implicit tests:

int Flags = 2;

if(TestFlagBool(1, Flags))

{

// Goes there

}

if(TestFlagInt(1, Flags))

{

// Goes there

}

I usually recommend implicit tests exactly for this reason: if some careless developer on the team changes the TestFlagBool function into a TestFlagInt function for optimization purpose, implicit tests make sure he does not break anything. If the code base is large enough, using explicit tests everywhere could prevent him from performing the optimization, because changing all the existing calling code would be too costly. Of course, whether the optimization is worth it or not is a case-by-case decision. But just in case it is, it is better to leave the option open.

Pierre Terdiman – June, 28, 2006