Re: Who owns a child view controller?
Re: Who owns a child view controller?
- Subject: Re: Who owns a child view controller?
- From: Alastair Houghton <email@hidden>
- Date: Fri, 14 Jul 2017 13:09:10 +0100
On 14 Jul 2017, at 12:03, Jeremy Hughes <email@hidden> wrote:
>
>> On 13 Jul 2017, at 20:29, Alex Zavatone <email@hidden> wrote:
>>
>> One thing that I had to learn was to break my expectations of when a view
>> controller (one that is tied to a navigationController) is deallocated.
>
> I’m not sure that view controllers are special. My understanding is that
> objects that are instantiated from a nib are not (usually or ever?)
> deallocated
Strictly, it depends which method you used to load the nib file. The older
(and IIRC deprecated?) methods used to load the top-level objects in a nib with
a non-zero retain count, which meant that they’d survive unless you explicitly
-release them (retain cycles notwithstanding), in spite of the fact that you
usually only have a reference to them if you’ve wired up an IBOutlet. The
newer methods don’t do that - instead, they pass out an NSArray containing
references to all of the top-level objects; any objects you don’t hold on to
directly (either by retaining the array or by retaining specific top level
objects) will be destroyed, either by ARC or via the surrounding autorelease
pool.
Both methods, strictly speaking, follow “normal” memory rules... which makes
more sense mainly depends on your view of what a nib file is. If you regard
the objects in the nib file as actual instances, then it makes sense that
they’d have a non-zero retain count - after all, they’re in the nib file,
right? If, on the other hand, you think of the nib loading system as
*creating* objects based on a nib file, the newer way makes more sense. The
newer approach also, I suspect, plays nicer with ARC and makes it less likely
you’ll accidentally leak objects from nibs you load.
> In addition to autorelease pools there could be other behind-the-scenes
> mechanisms (caches etc.) that have retain counts.
Indeed, and you might also find that some objects are singletons behind the
scenes, so could end up with quite unexpected retain counts. For instance,
there’s little point in having thousands of empty NSString instances, or
thousands of NSNumber instances containing 0 or 1. (I haven’t checked to what
extent this happens, but I imagine it does.)
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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