Re: ARC code in a non ARC app. iOS
Re: ARC code in a non ARC app. iOS
- Subject: Re: ARC code in a non ARC app. iOS
- From: Uli Kusterer <email@hidden>
- Date: Fri, 26 Feb 2016 07:43:36 +0100
On 24 Feb 2016, at 00:25, Alex Zavatone <email@hidden> 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 (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