On Jul 30, 2013, at 8:54 AM, Vincent Habchi <vi...@macports.org> 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 (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

Reply via email to