Re: static objects "autoreleased with no pool in place - just leaking"
Re: static objects "autoreleased with no pool in place - just leaking"
- Subject: Re: static objects "autoreleased with no pool in place - just leaking"
- From: "Louis C. Sacha" <email@hidden>
- Date: Fri, 13 Feb 2004 14:31:09 -0800
Hello...
Well, I just wanted to point out the potential problem, not just for
you, but for anyone else who might use similar code in their own
applications without realizing the implications (ie "I found it in
the archives, so it must be the right way to do it..."). As far as
being paranoid goes, they really are watching us from satellites in
the sky :)
Specifically, the issue I'm concerned with is the fact that the code
allocates static objects that should exist once per class in instance
methods that could potentially be run multiple times.
In your own code, if you can completely guarantee that there will
only be one instance of that particular class, then it won't cause
your application to break (although, in fact, even if there is only a
single instance of a particular class, awakeFromNib could potentially
be called multiple times). I would suggest that any variable that
relies on outlets being set, or requires object state information,
might be better as an instance variable (with an accessor method if
external access is required) instead of a global or static
variable... and particularly in the case of a singleton, wouldn't the
variables just be instance variables anyway?.
The only problem is that if anyone else attempts to use your code in
the future, in ways you didn't intend, things could go horribly
wrong. Again, it's your code, and no one else may ever use it, but
it's something to consider.
Just a friendly FYI, not a flame...
Louis
At 12:15 -0800 13/02/2004, Louis C. Sacha wrote:
Well, purists would generally frown on this too, but only because
you instantiate the objects in the init method. The problem is that
you will leak objects if the class is ever instantiated more than
once (which generally might not be the case for a class you use
specifically as the application delegate, but it's still better to
avoid the possibility).
The idea that my application delegate, a singleton object which I
instantiate inside my main NIB file, might be instantiated more than
once is... erhh... too paranoid for me :-). Should that ever happen,
so many other things would break that any concerns about leaking
some finite small number of objects would be insignificant.
The (self == [MyAppplicationDelegate class]) check is required
since you only want initialize to run once specifically for the
MyAppplicationDelegate class when it is initialized, not when any
potential subclasses are initialized...
The same holds for subclassing the application delegate class, which
_I_ would never do.
The correct way to do this within the implementation of a class
would be to use +initialize, which is called once for each class,
the first time the class is used.
Looking back into actual software I've written I find that I usually
initialize globals even later, inside awakeFromNib, because main
outlets should be connected at this point.
Sure, I suppose I could write an example where globals pointing at
objects might be referenced before the main nib file is loaded, but
I see little practical application for that...
--
Rainer Brockerhoff <email@hidden>
Belo Horizonte, Brazil
"It's extremely unlucky to be superstitious, for no other reason
than it is always unlucky to be colossally stupid." (Stephen Fry)
Weblog: http://www.brockerhoff.net/bb/viewtopic.php
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.