Re: Calling a Cocoa library from C
Re: Calling a Cocoa library from C
- Subject: Re: Calling a Cocoa library from C
- From: Thomas Davie <email@hidden>
- Date: Sat, 12 Nov 2011 23:02:00 +0000
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@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden