• 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: Releasing ivars in -didTurnIntoFault. Should set to nil?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Releasing ivars in -didTurnIntoFault. Should set to nil?


  • Subject: Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
  • From: Quincey Morris <email@hidden>
  • Date: Wed, 12 Aug 2009 21:04:01 -0700

On Aug 12, 2009, at 15:00, Georg C. Brückmann wrote:

I agree with that point. You may want to declare a macro like this:

#define INVALIDATE_REFERENCE(obj) ([(obj) autorelease], (obj) = nil)

The reason I chose autorelease over release are situations like the following: You register as a delegate of some object. Then the referenced object sends you a delegate message, to which you respond by clearing your reference to the said object. If at this time you’re sending the object its last release message, it will be deallocated. After your delegate message implementation returns, however, the formerly referenced and now deallocated object may continue executing the method from which it sent you the delegate message. And this is where you’d get into trouble using release instead of autorelease – you’d be in NSZombie hell.

And while this issue may not be relevant to managed objects, it certainly is relevant in other situations.

This doesn't sound like a valid argument. A *delegate* isn't responsible for keeping its referencing object alive, and *as delegate* is unlikely to keep a reference to the referencing object. (Typically, a delegate may serve multiple referencing objects, a pointer to which is passed as the first parameter of every delegate method. Any case where the delegate has to track which referencing objects use it sound incredibly atypical.)


In practice, the delegate is often -- independently of its role as delegate -- the *owner* of the referencing object (e.g. a window controller that is a delegate of a table view loaded from a nib file is the owner of the nib file's contents, including, directly or indirectly, the table view). However, in that case, there's no reason why the owner would relinquish ownership of the owned object during a delegate method.

Unless I'm missing something obvious.


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
      • From: "Georg C. Brückmann" <email@hidden>
References: 
 >Releasing ivars in -didTurnIntoFault. Should set to nil? (From: Jerry Krinock <email@hidden>)
 >Re: Releasing ivars in -didTurnIntoFault. Should set to nil? (From: "Sean McBride" <email@hidden>)
 >Re: Releasing ivars in -didTurnIntoFault. Should set to nil? (From: Dave Keck <email@hidden>)
 >Re: Releasing ivars in -didTurnIntoFault. Should set to nil? (From: "Georg C. Brückmann" <email@hidden>)

  • Prev by Date: Intermittent Console Log Entries '.sdef error' - Where from? What does it mean?
  • Next by Date: Re: NSArrayController access between nib files
  • Previous by thread: Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
  • Next by thread: Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
  • Index(es):
    • Date
    • Thread