Re: of nibs and top level objects
Re: of nibs and top level objects
- Subject: Re: of nibs and top level objects
- From: Paul Forgey <email@hidden>
- Date: Mon, 10 Apr 2006 12:33:52 -0700
Ughh this retain stuff can still be confusing. The meaning of his
comment finally struck me stupid:
// nibInstantiateWithOwner retains each top level object
[topLevelObjects makeObjectsPerformSelector:@selector
(release)];
Which means that we wasn't intending the objects to be left owned
by the array, but to be not doubly retained by being in the array.
I think this point might benefit from some discussion, if just for
the sake of the archives. From my view, it looks like this bit of
code is exactly written so that the top level objects (TLOs) are
left owned by the array, and the array alone.
Adding the objects to the array does not do a double retain. As
joar said, the TLOs have a retain count of 1 just by virtue of
being created by the Nib machinery. Once you place these TLOs into
the array they each have a retain count of 2. To properly
deconstruct the TLOs you need to not only release the array, but
also send all TLOs an individual -release message. The code quoted
above sends all of the TLOs a release immediately after being
placed into the array, so clients of the convenience method no
longer have to worry about this.
I am aware of the retain/release rules of container objects, but my
mental ref counts following the code was off by not reading it too
carefully. I had thought his code to get the top level objects was
intended to release all of them by simply releasing the array. What
he was actually doing (and rightly), was balancing things so that
releasing the array left the ref counts of the top level objects
alone as if we didn't get the array in the first place.
So really I ended up doing nothing by getting the array and then
releasing it. What I really needed to do was release all items in
the array, then the array.
Personally I think this is a little more complicated than it needs
to be. If you provide the Nib loading machinery with a TLO array,
why place the burden on the caller to release all these objects
manually before releasing the array? Furthermore, I feel like the
Nib machinery should require a TLO array, otherwise the caller is
certain to be leaking objects.
I would agree. NSNib helps out with this and I've since used it.
What object is it that needs 14 release events to reach 0? It
sounds a bit weird.
We're still talking about the nib owner..
I don't see how this can solve your problem. You're still just
doing the same thing - loading an nib file. There's something else
going on here, and I think you would do yourself a service if you
spent the time required to figure out what it is.
That's my two euro-cents worth of opinion anyway.
j o a r
I do understand perfectly well what is going on now. This solves my
problem because I've come to realize the top level objects really
RETAIN THE NIB OWNER. I had an extraneous retain count of 14, and 14
top level objects. Releasing all of these top level objects put
things back in balance.
This is also why I need a separate unload method. The object won't
dealloc until I do this for very obvious reasons.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden