Re: Simple dealloc question
Re: Simple dealloc question
- Subject: Re: Simple dealloc question
- From: John Stiles <email@hidden>
- Date: Mon, 15 Oct 2007 09:11:32 -0700
On Oct 15, 2007, at 7:25 AM, Alex Curylo wrote:
on 10/15/07 5:07 AM, email@hidden at
email@hidden wrote:
In my opinion, setting instance variables to nil in dealloc is a
cautious step too far. Any messages sent to the object in error after
dealloc could end up anywhere. What does it matter if the instance
variables point to released objects, when the receiver is itself a
released object?
Well, I can assure you unconditionally that in the C++ world it is
a class
of problem which routinely appears -- particularly when you're porting
Windows game code, because apparently no Windows game progammer has
ever
heard of [shared|auto|whatever]_ptr, grrrrr -- for code to access
deleted
objects that have not been overwritten, and for no apparent
problems to show
up with that until a very long time later, if you don't follow this
practice.
Even though Objective-C retain/release beats C++ smart pointers all
to hell,
it is still not unconditionally guaranteed that people will never
mess up
their memory management, I'm sure.
So, in any C++ project at all, setting instance variables to
obviously bogus
values on deletion is a good idea -- and in any C++ project that
has over a
dozen programmers, I'd move it up to a _vital_ idea, because it
_will_ save
you missed ship dates because of "that weird crash nobody can
reproduce"
sooner or later.
Maybe this class of problem just doesn't arise in the pretty
whiffle ball
Cocoa world so the OP's code cleaning out instance variables on nil
actually
is a cautious step too far here ... but to a grizzled scarred C++
programmer, "minimally prudent" would be more like it, because
anyone with
multi-dozen-programmer project experience has almost certainly
encountered a
massive problem which that level of prudence would have avoided all
but
completely.
I'm not sure the C++/Cocoa comparison is entirely valid here.
In C++, trying to use a NULL pointer almost always causes a crash.
In Cocoa, calling methods on a NULL object silently returns, which
does not help you find your stale-pointer/overrelease bug.
If anything, assuming you wanted to catch this sort of error in Cocoa
by crashing, you might set a different bogus pointer value, like
0xFFFFFFFF or something. Better still, though, would be to use the
built-in zombie detection code which is designed to catch exactly
these sorts of bugs.
_______________________________________________
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