On 21 Feb 2014, at 6:12 AM, jonat...@mugginsoft.com wrote: > I require an pointer to the value represented by an NSNumber.
(Assuming “value represented” means @1 -> 1, @HUGE -> HUGE.) > No interior pointer exists as the class is immutable. Immutability isn’t the point. The point is that the class is free to represent the value any way it wants. As you point out, integers in the range (I believe) +/- 2^55 are “stored” as tagged pointers; others in one form of internal data or another. > My best attempt, a category that shadows the represented value, is as follows > though I am wondering if I have missed a trick somewhere. > NSNumber uses tagged pointers and my unit tests indicate that the category > works okay with tagged pointers such as @(1). [elaborate code that uses size-for-subclass and runtime associated objects to get the represented value as NSData, and cache the NSData with each NSNumber; further use of the NSData not clear, nor why it may be assumed that every instance of [NSNumber numberWithFloat: 3.14] would deliver the same object with the same associated object] > Why do I need the pointer? > I am using NSNumber instances in collections as keys. (Assuming that the collections are sparse, so an array [a collection indexed by integers] isn’t practical. And if they aren’t integers, you’re in more trouble than this.) > In order to index a Mono collection with the NSNumber instance I require to > pass a pointer to the represented value to Mono. > All part of https://github.com/ThesaurusSoftware/Dubrovnik (A project large enough that I don’t have time to clear up what I’m not certain about.) Am I right that all you need is a pointer to a plain-old-data (C scalar) variable? Am I right in assuming that your Mono interface doesn’t care whether “5” is at a consistent address, so long as there’s a 5 in it? (Very strange otherwise.) And once the interface sees the value that’s pointed-at, it doesn’t keep the pointer? I must not understand, then, because this makes more sense to me: int five = 5; SomeMonoCall("here's two more than three: ", &five); I _know_ I’m missing something. Could you clarify? Also, if you _really_ need a consistent POD pointer for every NSNumber, and you can somehow work out the uniquing problem, why not have a “number” class that contains an NSNumber and a buffer big enough to contain the bits of any possible value? (You’d probably need a tag for the type, as well, but you see where I’m going. Do POD unions still work in ARC?) (And if you need to support all NSNumber methods as well, see -forwardingTargetForSelector:, which would be tedious to set up, but there should be tricks, and you can fall back on -forwardInvocation: to clear up unexpected selectors.) — F _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
