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 (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 arch...@mail-archive.com
