On 24 Feb 2016, at 00:25, Alex Zavatone <z...@mac.com> wrote: > Would it be recommended to package my ARC code with ARC turned off and > package that in a framework and then link to that from the non ARC app that > will need to load it?
Nope, that would leak all over the place, or dangle pointers depending on whether you're prone to using alloc/init and new to create your objects, or factory methods. Think of ARC this way: ARC manages memory for you (except for circles of strong references, aka retain cycles, those you have to resolve by marking back-references as weak) inside ARC-using source files. Basically, it inserts the requisite retain/release calls for you. So, once generated, ARC code is (for all we care for this discussion) undistinguishable from non-ARC code. However, you need to help ARC at the bridging point between ARC and non-ARC by following ObjC's naming conventions, and also by properly marking references as strong or weak. For your non-ARC classes that are referenced by ARC, this means if you have a -copyMachine factory method, ARC will see the "copy" and assume it's a method with copy semantics instead (+1 reference returned), and end up over-releasing the +0 reference of the factory method. The other way round is similar. If you create a -copyMachine method, ARC will just return a +1 reference from it and any other code using it must release it once done to avoid leaking. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://stacksmith.org _______________________________________________ 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
