Re: Who owns a child view controller?
Re: Who owns a child view controller?
- Subject: Re: Who owns a child view controller?
- From: Steve Christensen <email@hidden>
- Date: Fri, 14 Jul 2017 09:26:21 -0700
On Jul 14, 2017, at 8:09 AM, Jeremy Hughes <email@hidden> wrote:
>
>> On 14 Jul 2017, at 14:40, Steve Christensen <email@hidden> wrote:
>>
>> On Jul 14, 2017, at 3:50 AM, Jeremy Hughes <email@hidden>
>> wrote:
>>>
>>> I’m still not entirely clear on when autorelease pools are used in Swift.
>>> There is a WWDC video which says that they’re used in code that interfaces
>>> with Objective-C, but Greg Parker’s comments in this thread indicate that
>>> autorelease is also used behind the scenes in native Swift code - except
>>> that in many cases the compiler is able to optimise it out of existence.
>>> Apple’s Swift book doesn’t mention autorelease.
>>
>> I think the hazard here is that you are trying to build a mental model of
>> when to expect autorelease pools (or autorelease behavior in general) and
>> when not to. Worse, that you might design your code to fit those
>> expectations.
>
> Apple’s documentation states that there are times that you do want to
> consider the memory effects of autorelease pools (and suggests adding your
> own pools to prevent large accumulations of dead objects during loops) - so
> knowing when they are used isn’t irrelevant.
What I was getting at is that whether or not an object created by something
other than your code is in an autorelease pool should be of no concern to you
(at least with ARC). If your code assigns it to a strong variable, adds it to
an array, etc., then its retain count will be incremented because your code is
now becoming a [co-]owner of the object. Whether or not the retain count will
be decremented someplace else due to an enclosing autorelease pool or some
other mechanism will not affect that behavior.
If you explicitly create an autorelease pool, such as for reasons that you've
mentioned above, then you need to be aware that something you created in the
pool's scope, and want to continue existing beyond the pool's scope, could
magically disappear when the pool is drained if you're not managing it
correctly.
_______________________________________________
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