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: Bill Bumgarner <email@hidden>
- Date: Tue, 6 Jun 2006 10:26:40 -0700
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.
There are a couple of reasons for this.
First and foremost, during deallocation there can be no assertive
guarantees about the state of the object graph outside of the objects
the object being deallocated has retained. Any weak references or
indirect connections between objects may or may not be valid any longer.
Secondly, anything in a dealloc method that is not a deallocation
leads down a slippery slope. Because of the above, any action taken
on the part of the object that might cause notifications of any kind
or trigger other non-deallocation-centric code paths is very likely
going to cause a problem. It can also introduce order dependencies
-- debugging problems related to "this object needs to be deallocated
before that object so the observer is removed" kind of bugs is really
painful.
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!
b.bum
_______________________________________________
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