On 19 Aug, 2012, at 11:48 AM, Jens Alfke < email@hidden> wrote: On Aug 18, 2012, at 8:43 PM, Roland King < email@hidden> wrote: Interesting. I think I read a discussion about something similar and seem to recall that @YES and @NO do return kCFBooleanTrue and kCFBooleanFalse. Not to suggest for one second that @true and @false shouldn't do the what you suggest, did you try @YES and @NO at all?
*blink* I didn't even know there were @YES and @NO, although it makes sense that there would be. I'll give them a try. (I wish we could get away from the ancient legacy BOOL/YES/NO stuff, since C's had native booleans for 12 years now, but I digress.)
In that case, the encoding of @true and @false is even weirder, because based on their names, they ought to be "b", the C99/C++ "bool" type.
Thinking about it some more, I may know what's going on here.
@YES and @NO (as long as you are using a sufficiently recent version of Xcode and operating system, eg 4.4 for OSX 10.8) are specially defined literals which evaluate to kCFBooleanTrue/False, if you're on a version of the toolkit or OS less than that, they just aren't defined at all. @true and @false however are not special literals, so the compiler is just giving you a number literal with the numeric value of true and of false, ie 0 and 1. You get the same effect if you do @(YES) and @(NO) instead of @YES and @NO, the first two end up being NSNumber integer literals, the second two are NSNumber boolean literals.
This is one instance where the numeric literal syntax possibly violates the principle of least surprise. |