Re: Who owns a child view controller?
Re: Who owns a child view controller?
- Subject: Re: Who owns a child view controller?
- From: Greg Parker <email@hidden>
- Date: Wed, 12 Jul 2017 16:19:27 -0700
> On Jul 12, 2017, at 4:15 PM, Quincey Morris
> <email@hidden> wrote:
>
>> On Jul 12, 2017, at 14:57 , Jeremy Hughes <email@hidden>
>> wrote:
>>
>> I’m trying to understand memory management so I can avoid retain cycles and
>> other issues.
>
> There’s nothing wrong with trying to understand. The bet you will (almost
> always) lose is one involving reasoning about *when* retain counts reach
> particular values (such as 1 or 0).
>
> I may be overlooking something important, but I see basically three tasks you
> need to handle to avoid memory management bugs:
>
> 1. Strong references.
>
> In terms of object lifetimes, these are the easiest, because an object A that
> depends on an object B’s existence and keeps a strong reference to B is doing
> the right thing. There’s nothing here to worry about, assuming the reference
> to B is released normally (and *automatically* usually) when A deallocates.
> What you do have to worry about are reference cycles. You must either use
> something like Instruments to find any, and either avoid creating them, or
> ensure that you break them manually at a suitable time.
>
> 2. Weak references.
>
> This means zeroing weak references. (All weak references are zeroing since,
> IIRC, macOS 10.6.8.) Again, there’s nothing to do here, except to ensure that
> nothing crashes because a reference suddenly changes to nil.
>
> 3. Unowned/unsafe references.
>
> These are the killers. Typically, these are delegate references, but it’s
> hard to keep track of all the possibilities. For example, NSWindow’s
> “delegate” is still AFAIK unsafe. It’s usually set to the window controller,
> but I’m not aware of any typical bugs arising from this reference becoming
> invalid. The most common problem I know of is from table and outline view
> delegate and data source references. In many cases, it’s wise to nil these
> out manually when (say) your window closes.
We prefer to use "unretained" or "unsafe unretained" to describe this kind of
reference. "Unowned" means something else in Swift.
--
Greg Parker email@hidden <mailto:email@hidden> Runtime
Wrangler
_______________________________________________
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