Re: -[NSSet containsObject:] returns NO when it should return YES
Re: -[NSSet containsObject:] returns NO when it should return YES
- Subject: Re: -[NSSet containsObject:] returns NO when it should return YES
- From: Michael Crawford <email@hidden>
- Date: Fri, 04 Mar 2011 15:26:12 -0500
Creating the NSNumber objects using unsignedLongLong instead of longLong solved my problem. Thanks to everyone who participated in the lively discussion.
Sorry for being a little slow in closing the loop.
-Michael
On Feb 21, 2011, at 9:50 PM, Wim Lewis wrote:
>
> On 19 Feb 2011, at 2:17 PM, Michael Crawford wrote:
>> Anyone have previous experience with this problem? Can you shed some light on where my thinking and assumptions are wrong. I could write a sweet of tests to try and prove/disprove what I think is happening but I'm hoping to benefit from someone else's pre-existing research, experiments, or internal knowledge.
>
> One thing to check is to find two NSNumbers which you think should be equal, and see whether they return YES to -isEqual:. This is the form of equality which NSSet is interested in. (-hash is an optimization.)
>
>> I also assumed that whether or not the value is signed or unsigned; negative or positive makes no difference as long as calling the same accessor method on both NSNumber instances returns the same result.
>
> I think this is the false assumption that is giving you grief. Calling an accessor whose return type can't represent the NSNumber's value will return a value which has been converted according to C's casting rules (as far as I know). Consider two large numbers whose bottom 16 bits are the same; calling -unsignedShortValue on them will return the same value, but you wouldn't expect (or want) those numbers to compare equal.
>
> It looks like the contents of your noPlaySongs array were created using numberWithLongLong:. Is there a reason not to use numberWithUnsignedLongLong: to create them (as Greg Guerin suggests)? Or, ideally, never convert them to a C integer representation in the first place and treat them as if they were opaque objects (as Matt Neuburg suggests)? There's a fundamental difficulty, which is that there is no C type which can represent the values of all possible NSNumbers of integral types, (or even all C integers!), so roundtripping the number through a plain integer type is fraught with peril unless you know (or can figure out) which C type to use.
>
>
> (IIRC, there are still a few small warts in NSNumber/CFNumber's behavior which come from the fact that the numeric types implemented by CFNumber are not compatible with the numeric types implemented by NSNumber, and yet NSNumber is toll-free-bridged to CFNumber. I don't think this is related to your problem, though.)
>
>
_______________________________________________
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