Re: Memory Leaks and ARC
Re: Memory Leaks and ARC
- Subject: Re: Memory Leaks and ARC
- From: Dave <email@hidden>
- Date: Wed, 23 Apr 2014 20:45:42 +0100
Hi,
Yes, I realize that. But in this case, the root object obeys the new/alloc rule. it’s complicated because this App is a meld of 3 apps all developed at varying times.
In this case, there was an old-school network manager, that used manual MM. This was kept like that (by switching off ARC on a file-by-file basis) and a layer on top added like so:
Old-School Manual MM obeys new/alloc
NewLayer ARC - doesn’t not obey new/alloc.
The NewLayer is shallow and would be easy to change the names, then everything from the network layer should be NOT be auto-released.
I was thinking, what would be very useful is if the Static Analyzer would run the rules as if it were NON-Arc, that way it would generate a warning when the Chain was broken and an object was made auto-releasible.
Thanks for your help, I’m going to change the names and see if it makes a difference.
Cheers
Dave
On 23 Apr 2014, at 18:26, Quincey Morris <email@hidden> wrote:
> On Apr 23, 2014, at 03:01 , Dave <email@hidden> wrote:
>
>> If I changed the names of commandDownloadImageWithFileURLString to be newCommandDownloadImageWithFileURLString, this would cause it to release myImage on each iteration rather than using Autorelease?
>
> It would remove one — and perhaps the only — reason for ARC to use autorelease, but there’s no way of knowing whether there are others, hidden from you. For example, even if you create a new image using some alloc/init that returns the created object with +1 ownership, it may have already been autoreleased before it gets back to you.
>
> The outcome is also going to vary with the version of clang you compiled with, and the OS version you’re running on. The current clang already uses autorelease less often than the original implementation, and Cocoa classes may get converted from MRR to ARC gradually over OS releases.
>
> It seems to me that the best practice is:
>
> — Return objects with +1 ownership when semantically appropriate (when the caller gets an object that is conceptually new).
>
> — Investigate memory usage with Instruments, preferably on supported older OS versions too.
>
> — Bracket problem areas with @autoreleasepool{} only you’ve identified a problem area with Instruments.
>
> — Don't gratuitously insert @autoreleasepool{} in loops “just for safety”.
>
>> Is there anyway of telling if an Object is in “autorelease” state? I mean just for testing, I wouldn’t rely on this in shipping code.
>
> I don’t think so.
_______________________________________________
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