> On 13 Jul 2017, at 01:32, Jens Alfke <j...@mooseyard.com> wrote: > >> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes <moon.rab...@virginmedia.com> >> 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 <j...@mooseyard.com> 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 > <quinceymor...@rivergatesoftware.com> 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 (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
