bool a = static_cast<bool>(x);
bool b = x ? true : false;
bool c = (x == TRUE);
bool d = (x != FALSE);
bool e = !!x;
There's no need for any explicit conversion:
BOOL x = some_value; bool b = x;
The implicit conversion of a numeric type to
false for a value of
true for any non-zero value.
Incidentally, you've told us how
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 ? 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
x == 2, for example -- whereas
if (x) would still treat it as a true condition. Never compare boolean values for equality to
TRUE. (Comparing them to
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 is not appropriate if you need to distinguish among the multiple non-zero values.
Ultimately, I blame Microsoft for defining a 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 for a language that already has a perfectly well behaved built-in
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