Re: Mixing Obj-C and C "methods"
Re: Mixing Obj-C and C "methods"
- Subject: Re: Mixing Obj-C and C "methods"
- From: John McCall <email@hidden>
- Date: Tue, 30 Jul 2013 09:28:04 -0700
On Jul 30, 2013, at 8:54 AM, Vincent Habchi <email@hidden> wrote:
>> Apple's recommended alternative to having a struct contain an object is to use a class instead of a struct. You could create a MyCallbackInfo class with two properties: the query id and the pointer to self. You'd still have to bridge-cast *that* object when passing it to the callback.
>
> Makes me think of that French saying: “it’s like using a pneumatic drill to crack a nut”.
I would say that this is *a* recommended solution, and yes, it can be massive overkill. The __unsafe_unretained solution is more efficient if you can make it safe. If that’s not acceptable, __strong and __weak fields are allowed in Objective-C++, where the generated constructors and destructor will manage the retain/release operations for you; if you need to heap-allocate the struct, just be sure to use new/delete instead of malloc/free. All of these are reasonable solutions.
One final, ugly option that is *not* recommended but can nonetheless work is to make the field itself a void* and manage the lifetime manually with bridge casts.
Functions defined in the @implementation have access to private ivars because they’re clearly part of the implementation. Our recommendations about avoiding direct access to ivars are generally directed towards code that’s not part of the class’s implementation. Within the implementation, there can be many good reasons to directly access ivars; for example, you might specifically not want KVO to fire for some particular change, or you might not care about KVO and need the performance benefits of direct memory access, or you might not want to publicize getters or setters for the ivar.
John.
_______________________________________________
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