Re: Why should we set ivars to nil in dealloc?
Re: Why should we set ivars to nil in dealloc?
- Subject: Re: Why should we set ivars to nil in dealloc?
- From: "Adam R. Maxwell" <email@hidden>
- Date: Sun, 13 Apr 2008 12:41:42 -0700
On Apr 13, 2008, at 12:14 PM, j o a r wrote:
On Apr 13, 2008, at 10:48 AM, Ferhat Ayaz wrote:
why is it necessary to set the variable appointments (for instance)
to nil in this example? Should we do this for each variable? When
have we to do this?
You should rarely, if ever, have to do this if your code is
otherwise working correctly.
If you find that you need to set instance variables to nil in your
dealloc method, this would in the general case point to problems
_elsewhere_ in your code.
The reason would often be that you're doing "unsafe" things in your
dealloc methods. Dealloc should in general be reserved to simply
releasing your instance variables, and should not be overloaded with
other functionality.
And if the OP is interested, Bill Bumgarner has some helpful posts on
this in the archives.
Whenever you call out from your dealloc method (ie. any method you
call on some other object than self, and even any method on self
that you haven't implemented in your own class, or that could be
overridden by subclasses) you invite problems.
As a concrete example, I ran into exactly this problem with an
override of -[NSView discardCursorRects] (which had a radical
documentation change from 10.4 to 10.5 and now sounds much less
useful). NSView's dealloc invokes -discardCursorRects, and my
override was accessing an ivar that had already been deallocated. At
least that particular special case is now documented.
--
adam
_______________________________________________
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