How do I idiomatically convert a BOOL to a bool?

Question

The <windows.h> header comes with its own BOOL type. Peeking at the implementation, it seems FALSE is just a macro for 0, and TRUE is just a macro for 1, but I'm not sure this is specified.

What is the idiomatic way to convert a BOOL to a bool? I can imagine lots of possible ways:

bool a = static_cast<bool>(x);

bool b = x ? true : false;

bool c = (x == TRUE);

bool d = (x != FALSE);

bool e = !!x;

// ...

Answer 1

There's no need for any explicit conversion:

BOOL x = some_value;
bool b = x;

The implicit conversion of a numeric type to bool yields false for a value of 0, and true for any non-zero value.

Incidentally, you've told us how <windows.h> defines FALSE and TRUE. How does it define BOOL? (From your comment, it's typedef int BOOL;)

But some compilers may warn about this implicit conversion, even though it's perfectly valid code. Compilers are free to warn about anything they like, including the ugly font you used to write your code. g++, for example, doesn't complain about the conversion, even with:

g++ -std=c++11 -pedantic -Wall -Wextra ...

But according to this online Visual C++ compiler, VC++ does produce a warning:

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

Even with a static_cast, it still produces the warning.

You can avoid the warning by using !!x or x ? true : false. But I'm not sure the cure is any better than the disease.

The simple and correct way to do this is simply to assign the value and rely on the implicit conversion to do the right thing (it will).

If you have an additional requirement to avoid compiler warnings, then this becomes more a question about Visual C++ rather than the C++ language. There may also be some way to inhibit certain warnings without changing the source -- though that risks losing those same warnings when they actually make sense. In a comment, Dieter Lücking suggests:

#pragma warning(disable: 4800) // forcing value to bool 'true' or 'false' (performance warning)

but that looks like it still requires modifying the source. Perhaps there's something equivalent that doesn't.

One more thing: since BOOL is really type int, this proposed solution:

bool c = (x == TRUE);

is not equivalent to the others. Any non-zero int is treated as true, but only the value 1 is equal to TRUE. The above will set c to false if x == 2, for example -- whereas if (x) would still treat it as a true condition. Never compare boolean values for equality to true or TRUE. (Comparing them to false or FALSE is safer, but still unnecessary; that's what the ! operator is for.)

This all assumes that if you have a value of type BOOL, you only care whether it's falsish or truthy (zero or non-zero). Unfortunately, this may not always be the case. As Ben Voight's answer points out, Microsoft's API includes at least one function, GetMessage, that returns a BOOL result that is not a simple Boolean value. In such a horrible case, conversion from BOOL to bool is not appropriate if you need to distinguish among the multiple non-zero values.

Ultimately, I blame Microsoft for defining a type BOOL for a language that already has a perfectly well behaved built-in bool type. Actually that's not quite fair; it's used in APIs that need to be accessible from both C and C++. Microsoft's definition of BOOL probably goes back to their C implementation, where it makes some sense -- at least prior to C99, which Microsoft still doesn't support. (I don't know whether Microsoft's C compiler support _Bool. Even if it does, _Bool has some semantic differences from int, and changing the definition of BOOL might break some code -- particularly code that uses GetMessage.)

Answer 2

It's hard to say how would the win32 programmer do it, but IMHO it should be done by:

bool c = (X == TRUE);

or

bool d = (x != FALSE);

I think it's a bad practice to relay on macro (or any other predefined stuff)
constancy.

One day TRUE may become 0 and FALSE 1 ;)

Answer 3

There's no safe way to do it, because Win32 BOOL has more than two values.

Answer 4

I use a macro:

#define _bool(b) (!!(b)) 

IMO, makes my code more readable.

EDITED: a commenter has challenged my use of underscore in the macro name. To address this, here's a new version which is still generic and still uses the same name _bool, but is compliant, according to this.

namespace MyBool 
{
    template<typename T> inline bool _bool(const T b) 
    {
        return !!b;
    }
}

using namespace MyBool;

Answer 5

This is somewhat of an opinion question, but I think there are objective arguments to be made for the various options.

The best choice is:

bool d = (x != FALSE);

This makes the intent very clear to the reader, does not rely on implicit conversions, and makes it clear that there's more going on than a simple assignment.

The second best choice is:

bool b = x ? true : false;

But, to the casual reader, that can seem like a tautology.

I try to avoid implicit conversions in assignments because getting the wrong conversion is a surprising source of bugs. Even when I know the implicit conversion will do the right thing, I tend to do it explicitly, which may be helpful to someone reading the code in the future. Being explicit also allows you to keep the conversion warnings enabled so you catch the other implicit conversions you didn't know you were (ab)using.

The alternatives all have more serious drawbacks.

bool a = static_cast<bool>(x);

This is like hammering a square peg into a round hole. It's more elegant to write an expression that naturally returns the correct type.

bool c = (x == TRUE);

It's generally a bad idea to compare to TRUE, since other non-zero values would convert to false, which is almost certainly an error.

bool e = !!x;

Too clever compared to the alternatives that express exactly what you mean. (I am guilty of having done this in the past.)

bool f = x;

The performance warning MSVC++ emits on the purely implicit conversion seems fair. The compiler has to generate extra code to convert an int to a bool. The bare assignment gives little clue about this extra work. If it's in a tight loop, you might care. (Granted, the performance warning on the static_cast option seems egregious, but we've already ruled that out as less elegant.)

The d and b expressions clearly express the intent and make it obvious that there's more going on here than a direct assignment.