Re: Memory management question (passing objects to method)
Re: Memory management question (passing objects to method)
- Subject: Re: Memory management question (passing objects to method)
- From: Tim Lucas <email@hidden>
- Date: Fri, 4 Mar 2005 08:57:31 +1100
On 03/03/2005, at 11:22 PM, Dietmar Planitzer wrote:
I would strongly advice against calling setter methods from an
object's -init or -dealloc methods. The simple reason being that the
state of an object is by definition undefined while it is being
constructed or deconstructed. This is not a problem as long as you can
guarantee that other objects are not able to inspect the state of your
object while its executing its -init or -dealloc method. However, as
soon as -init or -dealloc calls a setter, the setter may make the
partially initialized / deallocated state of your object visible to
other objects by either:
1) Sending a notification
2) Sending an KVO observation message
3) Storing data on the undo stack
You have some very good points. I was under the impression Apple takes
the approach of using accessors in their dealloc. Is this correct?
Also, can anybody say for sure the automatic KVO notifications are
triggered when accessors are called from dealloc, or has this been
guarded against?
[msg snip]
I write all my setters in such a way that they always contain a bunch
of good old assert() macro invocations at the very beginning, where I
check that the passed in value is acceptable and in the valid range. I
then let the developer build of the application always run from inside
the debugger. This has the big advantage that when one of my setters
gets called with a bogus value, that the debugger instantly stops the
execution of the application at the point of the problem and prints
out a nice stack backtrace. This makes hunting down bugs much easier
as they get no chance to propagate away from the place of their
creation.
Most probably a good idea. Anybody else asserting params not nil in
their accessors? Any downsides?
- tim lucas
_______________________________________________
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