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: Public Look <email@hidden>
- Date: Fri, 13 Feb 2004 19:04:03 -0500
-awakeFromNib message is sent to all objects within a NIB that respond
to the message _AND_ the -awakeFromNib message is sent to the object
specified as the "owner" when the NIB is loaded: See +
loadNibNamed:owner:.
Apple's own docs say, "Typically, awakeFromNib is implemented for
classes whose instances are used as the owners of a loaded nib file
(shown as Files Owner in Interface Builder). Such a class has the
express purpose of connecting the loaded objects with objects in the
application and can thereafter be disposed of, or remain in the
capacity of a controller or coordinator for the loaded objects. For
example, suppose that a nib file contains two custom views that must be
positioned relative to each other at runtime. Trying to position them
when either one of the views is initialized (in initWithCoder: or a
setVariable: method) might fail, since the other views might not be
unarchived and initialized yet. However, it can be done in the nib file
owners awakeFromNib method (firstView and secondView are outlets of
the files owner):"
Suffice it to say that if the same object is specified as the owner
when multiple nibs are loaded, the owning object's awakeFromNib method
will be called at least as many times as the object is specified as the
owner.
On Feb 13, 2004, at 6:12 PM, Rainer Brockerhoff wrote:
>
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.
_______________________________________________
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.