bool vs BOOL

Intro

In windef.h you can find the following type:

typedef int BOOL;

There are several reason for microsoft choose BOOL writting code than bool.

• The C programming language uses "int" as its boolean type, and Windows 1.0 was written back when C was the cool language for systems programming.
• In seldom cases, return BOOL will have less assamble code than return bool.

This article will discuss the advantange and disadvantage for both of them. Though there was no standard said which is better, in exSDK, we try to use bool for all cases.

Performance

The following function, 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:

mov    ecx,dword ptr [esp+4]
mov    eax,1
shl    eax,cl
test   dword ptr [esp+8],eax
setne  al  
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:

mov    ecx,dword ptr [esp+4]
mov    eax,1
shl    eax,cl
and    eax,dword ptr [esp+8]
neg    eax 
sbb    eax,eax
neg    eax 
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:

mov    ecx,dword ptr [esp+4]
mov    eax,1
shl    eax,cl
and    eax,dword ptr [esp+8]
ret             

Latency Bugs

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.

Conclusion

Though BOOL really be faster when return value is integer, it leads to latency bugs, more on that, it will let the bool Property in exSDK become unused if user try to use BOOL for property ( it will becom integer in final GUI ). And for performance, it is seldom return integer for bool result, so it will not be a big deal. Based on the result, the conclusion to using bool or BOOL are:

• use bool in all places.
• use implicit tests in all places.
• when return value is BOOL (call win32 API), use "bool bSuccess = (theWin32API () != 0);" to resolve.