Re: Who owns a child view controller?
Re: Who owns a child view controller?
- Subject: Re: Who owns a child view controller?
- From: Jeremy Hughes <email@hidden>
- Date: Thu, 13 Jul 2017 10:57:36 +0100
> On 13 Jul 2017, at 01:32, Jens Alfke <email@hidden> wrote:
>
>> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes <email@hidden>
>> wrote:
>>
>> I’m trying to understand memory management so I can avoid retain cycles and
>> other issues.
>
> That’s fine. But using a weak reference to try to detect when an object gets
> dealloced is fraught with peril, viz. this entire thread :)
That was some test code I wrote to investigate a situation I noticed while
debugging. The actual issue is whether an object (view controller) is
deallocated rather than when it is deallocated.
> On 13 Jul 2017, at 01:32, Jens Alfke <email@hidden> wrote:
>
> If you want to find out if your code is leaking by creating reference cycles,
> just run it and ask either Instruments or Xcode to find leaks.
I was hoping to avoid creating cycles in the first place...
> On 13 Jul 2017, at 00:15, Quincey Morris
> <email@hidden> wrote:
>
> I may be overlooking something important, but I see basically three tasks you
> need to handle to avoid memory management bugs:
>
> 1. Strong references.
>
> 2. Weak references.
>
> 3. Unowned/unsafe references.
I’ve abbreviated this summary - but the things that I find confusing are:
1. When to use unowned rather than weak. I’ve read Apple’s Swift book and other
discussions, and one explanation I found is that unowned is a bit like forced
unwrapping - you can (or should) use it when you’re sure that the reference
will always be valid, and it saves you from having to use an optional.
According to Greg Parker’s email there is also unsafe unretained which is
different from unowned. I think that unsafe unretained is the same as
unowned(unsafe) in Swift, but I could be wrong.
There is a thread on Stack Overflow where people are confused about the
difference between unowned and unowned(unsafe).
https://stackoverflow.com/questions/26553924/what-is-the-difference-in-swift-between-unownedsafe-and-unownedunsafe
According to a comment from Dave Abrahams (who I think works at Apple):
"unowned and unowned(safe) do incur reference counting cost—that is the cost of
safety, and why even make unowned(unsafe) available otherwise?—and it’s
currently worse than regular strong reference counting cost because ARC isn’t
optimizing for it. Neither throws an exception; they trap when misused,
permanently stopping the program”
But if unowned is a synonym for unowned(safe), I’m not sure what “Neither”
means in the last sentence - is he talking about safe and unsafe unowned, or
just unsafe unowned?
Apple’s Swift book says:
"The examples above show how to use safe unowned references. Swift also
provides unsafe unowned references for cases where you need to disable runtime
safety checks—for example, for performance reasons. As with all unsafe
operations, you take on the responsiblity for checking that code for safety.
"You indicate an unsafe unowned reference by writing unowned(unsafe). If you
try to access an unsafe unowned reference after the instance that it refers to
is deallocated, your program will try to access the memory location where the
instance used to be, which is an unsafe operation.”
At this point I’m pretty confused about the difference between strong and safe
unowned. I understand that strong retains its reference, but it seems to me
that Dave Abrahams and Apple’s Swift book are saying or implying that (safe)
unowned also retains its reference - so the consequence of using (safe) unowned
incorrectly is that it will create a retain cycle, whereas using
unowned(unsafe) incorrectly will crash. But if unowned(safe) retains its
reference, how is it different from strong (apart from whether ARC is currently
optimising for it)?
2. When to use weak or unowned in closure capture lists (rather than default to
strong) is also pretty confusing! Presumably the default strong option is
correct for some or most closures, but I don’t have a very clear idea of when
it’s not correct.
3. Whether (and when) it’s necessary to avoid using functions or class
variables whose name begins with new or copy. I don’t think this is discussed
in Apple’s Swift book (or I haven’t found where it’s discussed), but I think
it’s necessary for classes that interface with Objective C in some way (e.g.
subclasses of Cocoa classes).
My experience of memory management in Objective-C and Swift (after many years
of experience with C and C++) is that it mostly “just works” (as Apple say in
the Swift book) - but there are many cases where you need a deeper
understanding and it’s hard to find clear explanations.
Jeremy
_______________________________________________
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