• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: static objects "autoreleased with no pool in place - just leaking"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 19:22:00 -0200

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.

  • Follow-Ups:
    • Re: static objects "autoreleased with no pool in place - just leaking"
      • From: "Louis C. Sacha" <email@hidden>
References: 
 >Re: static objects "autoreleased with no pool in place - just leaking" (From: Rainer Brockerhoff <email@hidden>)
 >Re: static objects "autoreleased with no pool in place - just leaking" (From: "Louis C. Sacha" <email@hidden>)

  • Prev by Date: Re: static objects "autoreleased with no pool in place - just leaking"
  • Next by Date: Re: NSAttributedString size method returning bogus data after adding NSParagraphStyle attribute
  • Previous by thread: Re: static objects "autoreleased with no pool in place - just leaking"
  • Next by thread: Re: static objects "autoreleased with no pool in place - just leaking"
  • Index(es):
    • Date
    • Thread