Note that of course you can take this one step further and use a typedef to
mask that you're passing back an untyped pointer:
typedef OCObjcCodeRef void *
OCObjcCodeRef OCCreateObjcCode(void)
{
return (ObjcCodeRef)[[ObjcCode alloc] init]
}
int OCGetFloatData(OCObjcCodeRef objcCodeRef, float *result1, float *result2)
{
ObjcCode *obj = (ObjcCode *)objcCodeRef;
@autoreleasepool
{
*result1 = [obj doSomeStuff];
*result2 = [obj doSomethingElse];
return [obj doMagic];
}
}
void OCReleaseObjcCode(OCObjcCodeRef o)
{
[(ObjcCode *)o release];
}
Which gets you roughly to the "toll free bridging" abstraction.
Tom Davie
if (*ra4 != 0xffc78948) { return false; }
On 12 Nov 2011, at 22:48, Greg Guerin wrote:
> Nathan Sims wrote:
>
>> Hmm, if not a global, where would the declaration go? The C function
>> certainly shouldn't return it, so if it is to remain persistent across
>> calls, wouldn't the logical (the only?) place for it be as a global in the
>> library's .m file?
>
>
> Why shouldn't the C function return it? As far as C is concerned, an object
> pointer is just an opaque pointer. Handle it like any other opaque pointer.
>
> Example:
>
> void * setup_data()
> {
> return (void *) [[ObjcCode alloc]init];
> }
> int get_float_data( void * ptrFrom_setup_data, float *result1, float *result2)
> {
> ObjcCode *obj = (ObjcCode *) ptrFrom_setup_data;
>
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>
> [obj call];
> *result1 = [more stuff];
> etc.;
>
> [pool drain];
> return 0;
> }
> void quit_data( void * ptrFrom_setup_data )
> {
> [(ObjcCode *)ptrFrom_setup_data release];
> }
>
> -- GG
>
>
> _______________________________________________
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/tom.davie%40gmail.com
>
> This email sent to [email protected]
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
