Re: NSNumber compare: Giving Unexpected Results
Re: NSNumber compare: Giving Unexpected Results
- Subject: Re: NSNumber compare: Giving Unexpected Results
- From: Chris Tracewell <email@hidden>
- Date: Wed, 8 Sep 2010 12:40:05 -0700
On Sep 8, 2010, at 12:02 PM, email@hidden wrote:
> It's not YES that's being "returned as" -256, but NO. (The answer is NO in all 3 cases.) -256 is 0xFFFFFF00, so you can see that NO (i.e. (signed char) 0) is being correctly returned in the low order byte, with trash in the high order bytes that's left over from earlier code.
>
> So, the problem is not your 'isLessThanZero' method, but the calling code, which is treating the returned value as an int (or something). Presumably the calling code was compiled with an incompatible declaration of your method, or of the BOOL type.
Thanks Quincey, your suggestion got me looking at the calling model and I got it working by first assigning the result as a BOOL rather than just using the result inside of an if logic statement like so...
// ========== Did NOT Work =========//
if ([theDecimalNumber isLessThanZero])
{
... do something
}
// ========== DID Work =========//
BOOL theResult = [theDecimalNumber isLessThanZero];
if (theResult)
{
... do something
}
I must admit that I do not understand why this is so. I can for example use if ([someButton isEnabled]) and it returns a BOOL and the if statement works fine. If you have any pointers or docs that explains this further I would really appreciate it as right now I feel scared about how I have been evaluating BOOL's returned in all of my own custom methods.
--chris_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden