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.