On Nov 12, 2011, at 12:01 PM, 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?
Not necessarily. For example, if your C library already allocates some kind of ‘context’ structure, you could add an ObjcCode* variable to that struct to store the object reference. I’m just pointing this out because using global variables in a library can create problems for thread-safety and re-entrancy. It’s often considered better design to put the library’s data into some struct/object that can be managed by the caller, so there could be a separate one for each thread or for independent clients. —Jens_______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
