Difference between revisions of "Boolean constants"

Revision as of 01:03, 25 October 2009

Remarks

If you test for a variable's truth value by testing if it is equal to TRUE you may not get the correct result since TRUE == x is a true expression only when x is 1, yet all non-zero values are also not FALSE; FALSE != x is true when x is not zero. There is an ambiguity whenever x is not 1 even though all non-zero values are treated logically as true. When x is 2, for instance, both TRUE == x and FALSE == x are false statements, leading one to conclude that x is neither TRUE nor FALSE when its value is 2 (or any other value besides 0 and 1). But this code snippet

int b_X_is_True = FALSE;
if( x ) b_X_is_True = TRUE;

will set the variable b_X_is_True to TRUE whenever the value of x is not zero. Clearly when x is 2 the language treats x as a true value logically.

The problem is that the identifier TRUE must be given a value, and that value must represent all non-zero values to be accurate. But a single value cannot represent many different values so there is ambiguity everywhere except at the value the constant is actually assigned. FALSE on the other hand, also needs to be given a value, but it only has to represent one integer value...zero, because that is the only integer value treated logically as false. Any integer value tested against FALSE will be unambiguously resolved. Because of this ambiguity with the TRUE identifier, and the correspondingly unambiguous nature of the FALSE identifier, you may wish to instead test if your variable is not equal to FALSE rather than testing its equivalence to TRUE.

Note also that it is never necessary, and furthermore wasteful, to explicitly "test for TRUE" or "test for NOT FALSE" in a boolean expression anyway. One would never write, for example:

if( (x == y) == TRUE ) ...  <-- redundant comparison with TRUE
if( (x == y) != FALSE ) ...  <-- redundant comparison with FALSE

because the sub-expression (x == y) will evaluate to TRUE or FALSE already. Additionally comparing the result to TRUE (or NOT FALSE) gives the exact same result for the entire expression as leaving the extraneous comparison out completely does. Thus the comparison with TRUE (or NOT FALSE) is redundant, unnecessary and a wasteful computation.

The same logic applies to expressions involving function calls. If a function returns a TRUE/FALSE value, it would be a redundant waste of CPU cycles to test if the returned value was TRUE.

if( IsObjectValid( oObject) == TRUE) ... <-- this is redundant as well
if( IsObjectValid( oObject) != FALSE) ... <-- as is this
if( IsObjectValid( oObject) ) ... <-- same thing, one less comparison

In this case the return value of the function (TRUE/FALSE) has the same logic characteristics as the sub-expression (x == y) in the example above. So you can treat the function call as a boolean sub-expression just like (x == y) and therefore the same logic leads to the same conclusion concerning the overall expression.

In contrast, testing for FALSE or for NOT TRUE is perfectly acceptable:

if( IsObjectValid( oObject) == FALSE) ... <-- this is not redundant
if( IsObjectValid( oObject) != TRUE) ... <-- not redundant either but is ambiguous
if( !IsObjectValid( oObject) ) ... <-- but this might be the best method

The identifier TRUE is only really useful for defining default values of boolean type parameters in a function definition, passing a true value to a function with a boolean parameter when you call it, or setting the value of a boolean type variable. There is no other place where you need it.

void Dance( int bChaCha = TRUE)... <-- default value in function def
SetItemDroppable( oItem, TRUE); <-- boolean parameter in function call
int bStillLooking = TRUE; <-- set a variable value

Some will probably take the position that having the extra comparison in there makes the code more readable and obvious. It would be difficult to argue that point especially in some more complex expression situations. But it is functionally unnecessary and adding it does waste CPU cycles in exchange for that marginal increase in readability. Learning to read expressions without it having to be there would benefit anybody.