On Sun, Oct 5, 2008 at 9:32 AM, Dr. Rolf Jansen <[EMAIL PROTECTED]> wrote:
> Am 05.10.2008 um 00:36 schrieb Michael Ash:
>
>> On Sat, Oct 4, 2008 at 4:01 PM, Dr. Rolf Jansen <[EMAIL PROTECTED]> wrote:
>>
>>> Mac OS X 10.5.5, Xcode 3.1.1, PowerBook G4.
>>>
>>> ...
>>> In order to prevent my application from crashing, I overwrote
>>> -[NSObject dealloc] of the datasource to the following:
>>>
>>> - (void)dealloc
>>> {
>>> return;
>>> [super dealloc]; // this prevents the warning that
>>> } // [super dealloc] is not called.
>>>
>>> Unbelievable, but true - I checked this several times, that this prevents
>>> my
>>> application from crashing.
>>
>> Not sure why you think this is unbelievable.
>
> Because I need to overwrite the system implementation, in order to prevent a
> crash.
Well it's not that you need to, but that you can. Of course abusing
the system can always cover up problems... for a while. :)
>> Absolutely not. Write your code to work with any order. In this case,
>> what you should do is write your data source to nil out the table's
>> reference to it when it goes away:
>>
>> - (void)dealloc {
>> [tableView setDataSource:nil];
>> [super dealloc];
>> }
>
> OK, thank you! That did indeed the trick.
>
> Anyway, now I cannot understand, why the NSTableView does not retain the
> dataSource, when it still needs it?
An excellent question! And you noticed the contradiction with my
advice below that objects should retain other objects that they need.
The quick answer is that NSTableView doesn't retain its data source in
order to avoid a retain cycle. It's quite common for the data source
to also be, say, the NSWindowController or a similar object which
implicitly or explicitly retains the NSTableView. If the NSTableView
also retained the data source, then in this scenario you would get a
big leak, as each one waited for the other one to be deallocated
before being deallocated itself.
Of course sometimes your data source *isn't* an owner of the
NSTableView, and then you blow up because your data source gets
deallocated first. As you've discovered.
(Incidentally, using garbage collection gets around this problem
nicely, as the collector can correctly deal with cycles of strong
references.)
For more information about this, see "Weak References to Objects" on this page:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html#//apple_ref/doc/uid/20000043
> This is clear to me now. Many thanks for your helpful response.
Glad to be of help!
Mike
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
