Re: crash when using notification center and self
Re: crash when using notification center and self
- Subject: Re: crash when using notification center and self
- From: "Pierce T. Wetter III" <email@hidden>
- Date: Tue, 6 Jun 2006 10:57:26 -0700
On Jun 6, 2006, at 10:26 AM, Bill Bumgarner wrote:
On Jun 6, 2006, at 10:11 AM, Pierce T. Wetter III wrote:
So if you have a class that gets added to NSNotificationCenter
as an observer dealloc is a good place to call:
[[NSNotificationCenter defaultCenter] removeObserver: self];
Convenient, yes.
Best practice? I'm not so sure.
My experience has been that investing a bit in ensuring that your
framework and underlying object graphs have a formal notion of "I'm
done with this object" that is different from deallocation.
I absolutely agree with this statement.
I'm not sure I agree that calling removeObserver: in dealloc is
"bad" per se despite your argument that at dealloc time things aren't
in a guaranteed state.
In almost all the cases where I've run into this particular
problem, having the object remove itself from the notification center
was the right thing to do.
That said, I'm sure either of us could come up with a case where
this was the wrong thing to do. Perhaps you're observing 1 of 10,000
objects. You don't want to make 9,999 extra calls to removeObserver:
in that case, instead, it should be the class that "owns" the 10,000
objects that should be registering/deregistering the observer.
A better answer would be that the class that registers the object
is responsible for unregistering the object before deallocation, even
if they're of different classes. However, I tend to have objects that
register themselves (self), so then its their responsibility to de-
register. Often that's in some sort of "doneWatching" method, but I
still end up needing the call in dealloc for the case where the user
closes the document in the middle of an operation or something.
The rules are different with KeyValueObserving vs.
NSNotificationCenter though. KVO observing is more automagic in my
experience.
Finally, the compiler man page mentions:
-fobjc-gc
Enable garbage collection (GC) for Objective-C objects.
The
resulting binary requires additional runtime support
which is not
present in any released version of Mac OS X.
If garbage collection ever becomes a reality for Objective-C, the
above goes from being a very good idea to being mandatory. I
spent years as a consultant cleaning up various random Java
projects. One of the most common bugs was one of scalability;
applications started to fail in mysterious ways as the load went
up. In just about every case, it was because there were classes
that relied upon the garbage collector to run at regular and
predictable intervals because the classes didn't clean up scarce
resources -- file descriptors and such -- until the finalize()
method. In many cases, the client would add RAM to the machine
(bumping the VM's memory footprint at the same time) and be
surprised as the problem only got worse!
Ironically, totally at random, the random WOTip signature on my
last post addressed just that issue. Here's a reprise:
WOTip: Set things to NULL when you're done with them. It makes the
JVM happy, and saves you GC time later.
More Tips: http://www.twinforces.com
I hope the ObjC referencing-counting/GC scheme works better then Java
does, I've always found it surprising how "sticky" Java and Python
are when it comes to hanging onto objects.
Like you, I've run into GC being a dual blessing/curse. You don't
have to think about a whole bunch of stuff, but instead you have to
think about how the GC system interacts with your program...
Pierce
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden