Ken is right about the internal representation of NSNumber not being something you can count on (as it is a class cluster). You should be able to count on the format of the data returned from its methods though (e.g. -integerValue, -floatValue).
Out of curiosity, are there any constraints on the numbers which will be used? If they are always integers, for instance, that makes the problem a lot easier. In that case I would use the -integerValue of the number and store it in NSData as a previous commenter suggested. If you need floating point values, then the entire problem becomes much harder, as using equality with floats is problematic in itself. Thanks, Jon On Feb 22, 2014, at 12:32 AM, Ken Thomases <[email protected]> wrote: >> In the above if key is an NSNumber containing a 5 then [key monoValue] >> returns a pointer to a 5. > > This betrays the flaw in your thinking. There's no such thing as "a pointer > to a 5"! You can have a pointer to an int which contains the value 5. Or a > long which contains the value 5. Or a char which contains the value 5. Or, > and this is the killer, a completely custom representation which only means > "5" when interpreted by the NSNumber's own methods. A pointer without the > knowledge of which specific storage type it's pointing to is almost useless. > Certainly, any recipient of that pointer could not reliably extract the value > 5 from it or compare it to any other pointer to see if they contain the same > thing. > > For example, what makes you think that two NSNumbers which compare equal have > the same size and byte-wise representation (as output by -getValue:) as each > other? First, one may have been created with +numberWithChar: and the other > with +numberWithUnsignedLongLong: and may have consequently used totally > different internal storage for the value. Second, there may be padding within > the internal representation which is ignored by NSNumber's methods but which > would make the data buffers unequal. _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
