When should BOOL and bool be used in C++?

Question

When should BOOL and bool be used in C++ and why?

I think using bool is cleaner and more portable because it's a built-in type. But BOOL is unavoidable when you interactive with legacy code/C code, or doing inter-op from .NET with C code/Windows API.

So my policy is: Use bool inside C++. Use BOOL when talk to outer world, e.g., export function in windows DLL.

Is there a definitive explanation of when to use one over the other?

Answer 1

Apparently, there's no good reason to use BOOL:

http://blogs.msdn.com/oldnewthing/archive/2008/03/25/8334558.aspx
http://blogs.msdn.com/oldnewthing/archive/2004/12/22/329884.aspx

Answer 2

Matthew Wilson discusses BOOL, bool, and similar in section 13.4.2 of Imperfect C++. Mixing the two can be problematic, since they generally have different sizes (and so pointers and references aren't interchangeable), and since bool isn't guaranteed to have any particular size. Trying to use typedefs or conditional compilating to smooth over the differences between BOOL and bool or trying to allow for a single Boolean type to work in both C and C++ is even worse:

#if defined(__cplusplus) || \
    defined(bool) /* for C compilation with C99 bool (macro) */
 typedef bool   bool_t;
#else
 typedef BOOL   bool_t;
#endif /* __cplusplus */

This approach means that a function's return type can differ depending on which language calls it; Wilson explains that he's seen more than one bug in his own code and others' that results from this. He concludes:

The solution to this imperfection is, as it so often is, abstinence. I never use bool for anything that can possibly be accessed across multiple link units—dynamic/static libraries, supplied object files—which basically means not in functions or classes that appear outside of header files. The practical answer, such as it is, is to use a pseudo-Boolean type, which is the size of int.

In short, he would agree with your approach.

Answer 3

Another situation where you should use BOOL: when implementing a callback function that takes or returns a BOOL.

For example, EnumWindows() takes a pointer to a callback function with the following signature:

BOOL CALLBACK EnumWindowsProc(      
    HWND hwnd,
    LPARAM lParam
);

If you use bool for this, you will have to typecast your function pointer.

Answer 4

If BOOL is some sort of integral type, and it always is, and BOOL is defined so that it works right, the standard conversions will automatically get it right. You can't quite use them interchangeably, but you can get close.

Use BOOL at the interface, where you have to talk to the Win32 API or whatever. Use bool everywhere else.

Answer 5

I think of "true"/"TRUE" and "false"/"FALSE" as syntactic sugar, a solution to a problem that never existed. I've always thought it easier to both use and read "1" and "0".

When you think about flags in registers being on or off, do you think in 1s and 0s or trues and falses? What happens if you want to store several flags in a single variable? 1s and 0s are universal.

I think the word "false" is too long for its own good. When I see a "0", it stands out in my mind like a red stop sign. Stop signs are red because the color red gets people's attention. Reading the word "false" is like seeing a green stop sign.

So, to hell with bool and BOOL. I default to int.

...but, really, getting boolean flags right is the least worry in a language with as many ways to make a mistake as C++.