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 11:45:58 -0700
On Sep 8, 2010, at 10:21 AM, email@hidden wrote:
> The message in the 'if' ([theNumOne compare:theNumTwo]) is an invocation of [NSNumber compare:], not [NSDecimalNumber compare:]. It's not absolutely clear what is supposed to happen when the compare parameter is an instance of NSDecimalNumber. Yes, NSDecimalNumber is a subclass of NSNumber, but these are abstract classes. The actual objects are (typically) concrete subclasses of the abstract classes, such as NSCFNumber. It's possible that this muddies the waters enough that the mixed comparison doesn't work as you would expect.
>
> In any case, why not simply do the comparison between 'self' and '[NSDecimalNumber zero]'?
Sorry for the last reply - I had the wrong subject line. I have nailed down that it seems that the BOOL is being returned as something other than char 1 || char 0 from the private framework where the category exists. The following works though, I know it's bad to use NSInteger values instead of BOOL but at this point I am at a dead end....
//=========== WORKS
-(BOOL)isLessThanZero
{
NSInteger theInteger = 0;
if ([[NSDecimalNumber zero] compare:self] == NSOrderedDescending)
{
theInteger = 1;
}
return theInteger;
}
--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