• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Who owns a child view controller?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Who owns a child view controller?


  • Subject: Re: Who owns a child view controller?
  • From: Quincey Morris <email@hidden>
  • Date: Fri, 14 Jul 2017 10:33:14 -0700

On Jul 14, 2017, at 03:32 , Jeremy Hughes <email@hidden> wrote:
>
>  one might argue that safe unowned objects could be replaced by
> unowned(unsafe) objects in release code

It’s highly desirable not to do that, because it’s the bugs that show up in
release code that are the hardest to find. In fact, Swift has a “stronger”
level of optimizations called “unsafe”, where the compiler just omits many of
the safety checks that you normally get even in release code. Whether this
turns of unowned reference counts is unknown to me.

It’s important (for compiler writers) to reason correctly in this area. Your
source code might have a couple of variables holding references to a particular
object, and one of those variables could by unowned. (There has to be at least
one owning reference as well, otherwise the object wouldn’t exist.) But primary
retain counts are incremented/decremented basically every time the reference is
*used*, which can be thousands or millions of times. Secondary retain counts
are incremented/decremented basically once per variable.

So, if the reference to a particular object is only every used once per
variable, secondary reference counting doubles to overhead, but only on
something whose CPU cost is vanishingly small. If the object reference is used
a lot, the contribution of the secondary retain count to overhead is
vanishingly small. There’s nothing to complain about here.

The only scenario I can think of where it might matter is when you’re creating
and destroying variables (as opposed to objects) a lot, such as having an
“unowned” local variable in the innermost scope of a tight loop. If you do that
to avoid the overhead of ARC inside the loop, you’re probably not achieving
your intention. But this is a very specialized scenario.

> I don’t think an unowned variable can be any kind of optional

Yes, it was just wishful thinking on my part. I recently ran into a scenario (a
“parent” pointer from a child back to its parent in a tree structure), where a
subtree might temporarily and validly have no parent. If the tree can be large
(hundreds of thousands of objects), making the “parent” pointer be “weak”
starts to become unpalatable, due the (presumed) overhead of a big side-table.
OTOH, the lifetime of a non-nil “parent” pointer is guaranteed to be less than
the lifetime of a child (because if it has a parent, its parent is retaining
it, by definition), so it seems like a good candidate for “unowned”.

> I was going to say I think the implicitly unwrapped optional in the Swift
> book example is a weak value

No, you can create reference cycles with IUOs as easily as with regular
variables. :)

Again, though, I recommend caution in terminology. I know what you mean here,
and I think *you* know what you mean here, but there’s no such thing as a “weak
value”. “Weak” is a property of the container, not the contents.
_______________________________________________

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

References: 
 >Who owns a child view controller? (From: Jeremy Hughes <email@hidden>)
 >Re: Who owns a child view controller? (From: Jens Alfke <email@hidden>)
 >Re: Who owns a child view controller? (From: Jeremy Hughes <email@hidden>)
 >Re: Who owns a child view controller? (From: Jens Alfke <email@hidden>)
 >Re: Who owns a child view controller? (From: Charles Srstka <email@hidden>)
 >Re: Who owns a child view controller? (From: Jeremy Hughes <email@hidden>)
 >Re: Who owns a child view controller? (From: Jens Alfke <email@hidden>)
 >Re: Who owns a child view controller? (From: Jeremy Hughes <email@hidden>)
 >Re: Who owns a child view controller? (From: Steve Christensen <email@hidden>)
 >Re: Who owns a child view controller? (From: Quincey Morris <email@hidden>)
 >Re: Who owns a child view controller? (From: Jeremy Hughes <email@hidden>)
 >Re: Who owns a child view controller? (From: Quincey Morris <email@hidden>)
 >Re: Who owns a child view controller? (From: Jeremy Hughes <email@hidden>)
 >Re: Who owns a child view controller? (From: Quincey Morris <email@hidden>)
 >Re: Who owns a child view controller? (From: Jeremy Hughes <email@hidden>)

  • Prev by Date: Re: Who owns a child view controller?
  • Next by Date: Re: Who owns a child view controller?
  • Previous by thread: Re: Who owns a child view controller?
  • Next by thread: Re: Who owns a child view controller?
  • Index(es):
    • Date
    • Thread