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 <quinceymor...@rivergatesoftware.com>
wrote:
> On Apr 23, 2014, at 03:01 , Dave <d...@looktowindward.com> 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 (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
