Re: Who owns a child view controller?
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