On Fri, Nov 21, 2008 at 9:13 AM, Ken Thomases <[EMAIL PROTECTED]> wrote:
> Next, even if you did want to construct an NSNumber from it, it's not a
> BOOL. So +numberWithBOOL: wouldn't be appropriate. Any non-nil object
> pointer would result in a true-valued NSNumber, even if [temp
> objectForKey:@"BBLMColorsSyntax"] had given you a false-valued NSNumber.
>
Wandering off the track a bit, but I think this is interesting....
It's actually not true that any non-nil object pointer will result in
a true-valued NSNumber. BOOL is not a true boolean yes/no type, but
rather it's just a signed char. This means that when you assign, pass,
or return a different numerical or pointer type in a place where BOOL
is expected the compiler will simply chop off the top bits to make it
fit. So if the last eight bits of your pointer all happen to be 0
(which is not that unlikely!) then your BOOL will be false instead of
true.
This can bite you if you try to take shortcuts with comparisons. For example:
- (BOOL)isNotNil:(id)obj {
return obj != nil;
}
Pretend for a moment that this method is not actually completely
pointless. So you say, but any non-nil value for 'obj' is always true,
so I can remove the comparison and just write this:
- (BOOL)isNotNil:(id)obj {
return obj;
}
Now you've set yourself up for a nasty intermittent failure. This will
work correctly, *most* of the time. But on a significant percentage of
non-nil 'obj' values, you'll get NO back.
Yeah, I did this once (with a less-pointless method, of course) and it
bit me. Fun times debugging that....
Mike
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
