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: Rainer Brockerhoff <email@hidden>
- Date: Fri, 13 Feb 2004 21:12:35 -0200
At 14:31 -0800 13/02/2004, Louis C. Sacha wrote:
>
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 :)
You don't say! I thought my aluminum-foil showercap took care of those? ;-)
>
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.
Of course, if you put it like that, you're right; especially as the original poster clearly wanted to emulate some C++ behavior. However, I usually use globals more in the C way: things that several otherwise unrelated classes, or functions, need to refer to.
>
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).
Can you cite a specific instance? What could cause a Cocoa application's main nib to be loaded multiple times (other than the programmer reloading it explicitly)?
Anyway, in that case, one could use the same idiom as for static local variables:
NSColor* red = nil;
...
if (red==nil) red = [[NSColor redColor] retain];
>
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?.
For internal (encapsulated in a class) variables, certainly. Again, any globals I use are for application-wide variables.
>
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...
I agree with you that publishing source or working on a team with other programmers (both of which I've done _very_ few times) demands stricter standards here.
--
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.