Re: NSTextView won't deallocate
Re: NSTextView won't deallocate
- Subject: Re: NSTextView won't deallocate
- From: Kyle Sluder <email@hidden>
- Date: Mon, 18 Jul 2011 16:09:59 -0700
On Mon, Jul 18, 2011 at 3:55 PM, Ryan Joseph <email@hidden> wrote:
> ;) I was being stupid in that example, I see how my ownership was still retained until I called release (for NSTextView.alloc.initWithFrame) and removeFromSuperview (for parent.addSubview). Since there's nothing strange with NSTextView like I originally thought I just need to pay very close attention to where I'm retaining it in my code.
Well, there _is_ something strange about NSTextView, but it's just
something you shouldn't normally have to care about.
NSTextView supports two ownership graphs, as described in the
documentation that "R" linked to as well as this documentation here:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/TextArchitecture/Tasks/AssembleSysByHand.html#//apple_ref/doc/uid/20000843-CJBBIAAF
In the simple case (initialized using -initWithFrame: or unarchived
from nib), the NSTextView owns all the other objects in the graph. If
the text view gets deallocated, it releases its layout manager, text
container, and text storage.
In the more complicated case (initialized using
-initWithFrame:textContainer:), the NSTextStorage owns all the other
objects. If the text storage gets deallocated, it releases its layout
manager(s), text container(s), and text view(s).
The implementation of this dual ownership scheme involves a custom
-retain/-release implementation that can result in a text storage with
a higher-than-expected retain count before deallocation (I believe
there's actually code in -[NSTextView release] along the lines of `if
(retainCount == 4) [self dealloc];`).
If you don't peek at -retainCount, as recommended by the Memory
Management Programming Guide, and mandated by the forthcoming ARC
technology, this doesn't affect you. But it's something you should
still be aware of, particularly if you want to swap out bits and
pieces of the text system. While you don't have to manage the
lifecycle of the internal components, you do have to be careful to use
the correct methods to swap them out of place without disturbing the
black ownership voodoo going on.
But none of this really affects your original issue: someone who had
an owning reference to your text view called -autorelease instead of
-release. Since superviews retain their subviews, I bet that
-removeFromSuperview is expressly written this way so that you can
safely remove a view from its superview without having to do the
[[subview retain] autorelease] dance to make sure removing it from its
superview doesn't immediately deallocate it.
The retainCount being 4 is just a red herring.
--Kyle Sluder
_______________________________________________
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