Re: Why do we use -fobjc-arc instead of removing code with #define?
Re: Why do we use -fobjc-arc instead of removing code with #define?
- Subject: Re: Why do we use -fobjc-arc instead of removing code with #define?
- From: Jean-Daniel Dupas <email@hidden>
- Date: Tue, 26 Jun 2012 11:34:23 +0200
Le 26 juin 2012 à 11:24, Uli Kusterer a écrit :
> On 26.06.2012, at 03:20, Graham Cox wrote:
>> On 26/06/2012, at 7:42 AM, Greg Parker wrote:
>>> We recommend each file be written for either one or the other, with no attempt to be ARC-agnostic.
>>
>> Does this imply that ARC can be adopted gradually?
>
> Yes. ARC (effectively) generates the release/retain statements for you, so as long as none of your headers in some way expose code that might be ARC or non-ARC, and you follow the naming conventions, you can turn ARC on/off per compilation unit (i.e. "source file").
>
>> For example, I have a large project that uses manual memory management. If I add a new class to it, can I write that class with ARC without having to adopt it for the whole project? I've been able to do that with properties and other Obj-C 2.0 stuff very successfully, but it wasn't clear that ARC could be managed the same way. If it can be done, how is ARC enabled for a specific class?
>
>
> Haven't yet had to use it, but Stack Overflow (http://stackoverflow.com/questions/8768176/how-to-add-arc-for-specific-file) says the flag is logically named "-fobjc-arc". Just specify that for a source file.
>
You may have to pass this flag to the linker too, at least if you target 10.6, to let the linker know it has to link using the ARC runtime library.
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
-- Jean-Daniel
_______________________________________________
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