• 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: Notification from dealloc and overiding retain/release scheme
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notification from dealloc and overiding retain/release scheme


  • Subject: Re: Notification from dealloc and overiding retain/release scheme
  • From: "John C. Randolph" <email@hidden>
  • Date: Tue, 17 Sep 2002 11:44:45 -0700

I take it that you need to tell some other object when this one is going to be deallocated. I understand the looping problem you describe below, but I would not recommend overriding -release under these circumstances. (In fact, the only case I can think of in which I would override release is if I'm implementing a singleton.)

First question: does the object getting the notification *really* need to know the address of the object that's getting deallocated?

Second question: If the receiver of the notification cares whether this object goes away, why hasn't it retained it?

On Tuesday, September 17, 2002, at 04:59 AM, Girard Iglesias wrote:

Hello,

I made some search around this subject on the archive

And saw that it is not a good idea to send notification from the
dealloc method with self as the object parameter.

But I am working on code containing this kind of stuff, and it worked
very well until I fall on a new use where the object deallocated and
sending a notification is also overriding retain/release scheme.

if the release is coded like :

- (void)release
{
refCount--;
if (refCount == 0)
[self dealloc];
}

then we enter in a 'infinite loop' ;)

dealloc -> notification -> retain -> release-> dealloc -> notification
-> retain > release -> .....


Hopefully, notification release directly, not by autorelease, hence I
found almost quickly the problem (a lot of class and code in the code I
have to maintain...)

But this stuff does work very well with object that not override
release, it seems that we need to know that an object is dying:

- (void)release
{
refCount--;
if (![self isDying] && refCount == 0)
[self dealloc];
}


Seems to be costly not, I didn't find anything in the runtime? maybe an
hidden function.

I can send an example of this stuff...

Obviously I can solve the problem by sending the address of the object
as a number in the 'info dict' of the notification. But I am surprised
that it is not documented...

-jcr

John C. Randolph <email@hidden> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html
_______________________________________________
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.

References: 
 >Notification from dealloc and overiding retain/release scheme (From: Gérard Iglesias <email@hidden>)

  • Prev by Date: Re: NSData Deprecations
  • Next by Date: Re: Menus of any other app...
  • Previous by thread: Re: Notification from dealloc and overiding retain/release scheme
  • Next by thread: Protected Nib
  • Index(es):
    • Date
    • Thread