# BOOL / bool / Boolean / NSCFBoolean

Truth. Vēritās. The entire charter of Philosophy is founded upon the pursuit of it, and yet its exact meaning and implications still elude us. Does truth exist independently or is it defined contingently against falsity? Can a proposition be at once both true and false? Is there absolute truth in anything, or is everything relative?

Encoding our logical universe into the cold, calculating bytecode of computers forces us to deal with these questions one way or another. And, as we’ll soon discuss, truth is indeed stranger than fiction.

We’ve talked before about the philosophical and technical concerns of nothingness in programming. This week, our attention turns to another fundamental matter: Boolean types in Objective-C.

In `C`, statements like `if` and `while` evaluate a conditional expression to determine which code to execute next. A value of `0` is considered “false” while any other value is considered “true”.

Objective-C defines the `BOOL` type to encode truth values. Altogether, `BOOL` comprises a type definition (`typedef signed char BOOL`) and the macros `YES` and `NO`, which represent true and false, respectively. By convention, we use the `BOOL` type for Boolean parameters, properties, and instance variables and use `YES` and `NO` when representing literal Boolean values.

## The Wrong Answer to the Wrong Question

Novice programmers often include an equality operator in conditional expressions:

``````if ([a isEqual:b] == YES) {
...
}
``````

Not only is this unnecessary, but depending on the left-hand value can cause unexpected results, as demonstrated by Mark Dalrymple in this blog post with the following example:

``````static BOOL different (int a, int b) {
return a - b;
}
``````

A clever programmer might take some satisfaction in this approach. Indeed, two integers are equal if and only if their difference is `0`. However, because `BOOL` is `typedef`‘d as a `signed char`, this implementation doesn’t behave as expected:

``````if (different(11, 10) == YES) {
printf ("11 != 10\n");
} else {
printf ("11 == 10\n");
}
// Prints "11 != 10"

if (different(10, 11) == YES) {
printf ("10 != 11\n");
} else {
printf ("10 == 11\n");
}
// Prints "10 == 11"

if (different(512, 256) == YES) {
printf ("512 != 256\n");
} else {
printf ("512 == 256\n");
}
// Prints "512 == 256"
``````

This might be acceptable for JavaScript, but Objective-C doesn’t suffer fools gladly.

Deriving truth value directly from an arithmetic operation is never a good idea. Like the sentence “Colorless green ideas sleep furiously”, it may be grammatical but it doesn’t make any sense. Instead, use the result of the `==` operator or cast values into booleans with the `!` (or `!!`) operator.

## The Truth About `NSNumber` and `BOOL`

Pop Quiz: What is the output of the following expression?

``````NSLog(@"%@", [@(YES) class]);
``````

Answer: `__NSCFBoolean`

Wait, what?

All this time, we’ve been led to believe that `NSNumber` boxes primitives into an object representation. Any other integer- or floating-point-derived `NSNumber` object shows its class to be `__NSCFNumber`. So what gives?

`NSCFBoolean` is a private class in the `NSNumber` class cluster. It’s a bridge to the `CFBooleanRef` type, which is used to wrap boolean values for Core Foundation property lists and collections. `CFBoolean` defines the constants `kCFBooleanTrue` and `kCFBooleanFalse`. Because `CFNumberRef` and `CFBooleanRef` are different types in Core Foundation, it makes sense that they are represented by different bridging classes in `NSNumber`.

Name Typedef Header True Value False Value
`BOOL` `signed char` objc.h `YES` `NO`
`bool` `_Bool` (`int`) stdbool.h `true` `false`
`Boolean` `unsigned char` MacTypes.h `TRUE` `FALSE`
`NSNumber` `__NSCFBoolean` Foundation.h `@(YES)` `@(NO)`
`CFBooleanRef` `struct` CoreFoundation.h `kCFBooleanTrue` `kCFBooleanFalse`

For most people, Boolean values and boxed objects “just work”. They don’t really care what goes into making the sausage. But here at NSHipster, we’re all about sausages. That’s the honest truth.

NSMutableHipster

Questions? Corrections? Issues and pull requests are always welcome.

Written by
Mattt

Mattt (@mattt) is a writer and developer in Portland, Oregon.

Next Article

# NSSecure​Coding

A short post for this week: everything you need to know about NSSecureCoding.