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: Tony Becker <email@hidden>
- Date: Mon, 14 Apr 2008 08:29:27 -0400
OK. My $0.02
To answer the original question...
We live in an Object world, where we like to re-use things.
So, for example, I have an object hierarchy of view controllers.
In -awakeFromNib:, I use a instantiate and use a iVar. In dealloc, I
release it.
However, under the covers, I DON'T call [super -awakeFrommNib:],
because my parent didn't awake from his .nib.
But, in dealloc, I call [super dealloc], so my parent gets called
(and eventually NSObject)
Assuming that, in his awakeFromNib:, my parent used the same iVar (or
more correctly, I'm re-using it), he too will release it, which is BAD.
So, he needs to check if it's nil before releasing it (yes, Obj-C
will ignore the release to a nil object), and thus, more importantly,
and to the question at hand, I need to set it to nil, in my dealloc,
when I'm done with it.
Technically, you got the ivar nil-ed out, and it's good form to put
it back the way you found it.
On Apr 13, 2008, at 11:39 PM, Bill Bumgarner wrote:
On Apr 13, 2008, at 6:35 PM, Ben Trumbull wrote:
Seriously, we're arguing about this ?
If you want a total hack, just assign (id) 0x1 to any variable that
... please step away from the tequila.
Heh. No amount of testing (see below for framing of this statement)
will catch every fault. I like my software to fail
catastrophically throughout the beta period (or pre-submission
period, in many cases) if anything I didn't catch in testing falls
through the cracks. Nor can you expect to have all the full-on
testing goop enabled outside of your development environment.
For example, how long does the typical app run for with libgmalloc
hanging out and chewing up pages?
....
Running unit tests through debugging tools (zombies, leaks, etc)
nightly has been the single highest return on effort debugging
decisions I've ever seen.
Ever. Seen.
The second highest was actually writing the unit tests in the first
place, a necessary prerequisite, but more effort.
Just imagine what you could do mixing this stuff with dtrace ...
But, really, what Ben said. Seriously. Unit tests, automated
tests, and doing them continuously goes a really really long way to
minimizing defect analysis pain.
Applying the system provided analysis tools during testing runs is
relatively easy and extremely useful, too. The tools are there,
might as well use 'em.
b.bum
_______________________________________________
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
_______________________________________________
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