On 21 Feb 2014, at 19:07, Fritz Anderson <fri...@manoverboard.org> wrote
> int five = [@((int)5) intValue];
> SomeMonoCall("here's two more than three: ", &five);
The above is basically correct - note that I edited it a bit.
A basic point here is that you cannot take the address of an rvalue like so
&[@((int)5) intValue];
Hence the need for the intermediate lvalue declaration int five.
Note also that lvalue needs to be declared in the same function when allocating
on the stack.
So no passing pointers to local variables out of functions.
>
> I _know_ I’m missing something. Could you clarify?
I have an NSNumber containing 5.
The NSNumber instance is a key in a dictionary collection.
In order to obtain the value I need to pass a pointer to a memory location
containing 5 to Mono.
However not all keys in the dictionary need be NSNumber instances, they may be
NSStrings.
If this case to obtain the value I need to pass a pointer to a memory location
containing a Mono data structure.
So:
[DBObject_key -monoPtr] returns a (void *).
[NSString_key -monoPtr] returns a MonoObject *
[NSNumber_key -monoPtr] returns say an int*.
So I want to be able to send the same message to any class and get an
appropriate void* pointer.
This usage pattern, within a generated code environment too, makes the
imposition of an lvalue that I can take an address from undesirable.
Does that add or remove clarity!
>
> 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?
>
> (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.)
I know what you mean.
I looked at other solutions, including Obj-C’s faux version of multiple
inheritance utilising -forwardingTargetForSelector.
But I didn't really want to subclass NSNumber, all of the xxxValue methods need
overridden if the subclass supports all of the native NSNumber encoded types (+
the primitive methods of NSValue).
Plus it also needs to be an NSNumber, not a custom NSObject subclass.
Thanks for looking.
Jonathan
_______________________________________________
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
