On Feb 23, 2016, at 15: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?
This would be a really bad idea. :) Your code has no retains and releases, so it will cause crashes unless it is compiled with ARC turned on. Think of it this way: ARC does the retains and releases for you. Either you *compile* with ARC, or you *compile* with explicit retains and release. Anything else will crash. Packaging the compiled code doesn’t affect this. On Feb 23, 2016, at 15:29 , Alex Zavatone <z...@mac.com> wrote: > > Are there any tools in Instruments or approaches to make sure I'm not going > to destroy the universe when calling my stuff? I don’t think you’re in danger of destroying any universes, but I don’t know that there’s anything automatic to help you. The main problem is that your (ARC) code needs to know the memory management of the other (MRR) code. That means that any headers it imports from the other code must not promise things that aren’t true. That includes property attributes such as ‘strong’, ‘unowned’, and assumptions that ARC makes about memory management based on naming. (For example, an object obtained via [[…alloc]init…] is generally assumed to be returned with a +1 ownership, but an object obtained via a class method named ‘newXXX…’ is generally assumed to be returned with +0 ownership.) So it’s certainly possible that the other code’s header files may be non-specific enough to cause headaches in your ARC code. You’re probably pretty safe in the other direction, since ARC follows the memory management conventions that well-written MRR code used to use. Perhaps your other choice is to use copies of your code, and add the MRR retains and releases back in. _______________________________________________ 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
