Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > Developer Center > dealloc, release & autorelease

dealloc, release & autorelease
Thread Tools
Professional Poster
Join Date: Oct 2001
Location: London
Status: Offline
Reply With Quote
Dec 6, 2001, 05:42 AM
 
Am I right in thinking that the dealloc method of an object is called in-directly when sending it release (or autorelease) messages?

This is never explicitly stated in the "learning cocoa" book, but seems to be implied - also by experimenting using NSLog in my dealloc method, it seems to be true.


2nd Question - I want to think about object ownership in the correct way (so that I can write clean non-leaky code.) However, I'm still a bit confused and I was wondering if I have understood it properly.

I have a fleetingly existing object (myObject) and it has a method 'name:' which returns an NSString.

I also have an NSTextField in a window that stays open (effectively forever.)

If I use the following code:

[anNSTextField setStringValue: [myObject name]];
[myObject autoRelease];

is this correct? My thought process is this:

anNSTextField has set its string value to a reference to an NSString returned from myObject.

This is in fact a refence to an NSString object within myObject.
When I autorelease myObject anNSTextField will retain myObject until its stringValue changes (at which point it will no-longer retain myObject and the autorelease pool will release myObject.)

Is this the right kind of thinking?
     
Grizzled Veteran
Join Date: Apr 2001
Status: Offline
Reply With Quote
Dec 6, 2001, 11:00 AM
 
Originally posted by Diggory Laycock:
Am I right in thinking that the dealloc method of an object is called in-directly when sending it release (or autorelease) messages?
Yes and no.

The object is deallocated (and dealloc called) only if the object's reference count reaches zero. If you created the object and then send it a release, its reference count was only 1 and was decremented to zero when you sent the release, so yes, it is dealloc'ed.

However, if you create the object, and perhaps pass it around to a lot of other methods, some of which may retain it, the reference count may be higher than 1 when you send the release message. This will decrement the reference counter, but if it's not zero after being decremented, it will not be dealloc'ed.

As for autorelease, the reason autorelease exists is simple: you should never release an object you didn't create or cause it's creation (say through a convenience method). So, if you call method B, how can method B create an object and return it to you since you're not allowed to release it?

The answer is autorelease. Method B creates the object, and then sends it autorelease and returns it to you. You have time to copy or retain the object if you want to keep it. If you don't, the next time the autorelease pool is walked, the object will be released. If nobody retained it, it will also be dealloc'ed.

2nd Question - I want to think about object ownership in the correct way (so that I can write clean non-leaky code.) However, I'm still a bit confused and I was wondering if I have understood it properly.

I have a fleetingly existing object (myObject) and it has a method 'name:' which returns an NSString.

I also have an NSTextField in a window that stays open (effectively forever.)

If I use the following code:

[anNSTextField setStringValue: [myObject name]];
[myObject autoRelease];

is this correct? My thought process is this:

anNSTextField has set its string value to a reference to an NSString returned from myObject.

This is in fact a refence to an NSString object within myObject.
When I autorelease myObject anNSTextField will retain myObject until its stringValue changes (at which point it will no-longer retain myObject and the autorelease pool will release myObject.)

Is this the right kind of thinking?
Hmmm...we really need a Cocoa expert on this one. According to the guideline I posted above, you're correct. NSTextField didn't create the string object. Therefore if it wants to guarantee it will be around, it needs to copy or retain it. But I'm not sure if that's really how it works. We need a Cocoa guru to answer.

Wade
     
Forum Regular
Join Date: Oct 2001
Location: Sweden
Status: Offline
Reply With Quote
Dec 6, 2001, 12:31 PM
 
Originally posted by Diggory Laycock:
<STRONG>If I use the following code:

[anNSTextField setStringValue: [myObject name]];
[myObject autoRelease];

is this correct?</STRONG>
Actually you could just as well use release instead of autorelease here, unless you need autorelease for some special reason - e.g. you're returning it from the method.

The basic idea about reference counting and passing objects around is that if you want something to stick around, copy it or retain it. The same rules apply for the classes that are a part of Cocoa. In this case the text is actually copied by the NSTextField. How do I know that? Well you could pass a NSMutableString to setStringValue, and if I were a NSTextField, I wouldn't want my text to suddenly be changed by someone else - thus I'd copy it.

What's nice about Cocoa is that you don't have to think about details like this if you don't want to. Just concentrate on your own code, and make sure that you match every init/copy with a release/autorelease. What others do with the stuff you pass them is up to them. Trust Apples classes to do the right thing(TM).
     
tie
Professional Poster
Join Date: Feb 2001
Status: Offline
Reply With Quote
Dec 6, 2001, 05:39 PM
 
Originally posted by Diggory Laycock:
<STRONG>My thought process is this:

anNSTextField has set its string value to a reference to an NSString returned from myObject.

This is in fact a refence to an NSString object within myObject.
When I autorelease myObject anNSTextField will retain myObject until its stringValue changes (at which point it will no-longer retain myObject and the autorelease pool will release myObject.)

Is this the right kind of thinking?</STRONG>
Exactly as tobli says, you don't need to worry about it, regardless of how the NSTextField uses your string. Either it makes a copy -- fine -- or it simply <font color = blue>retain</font>s it -- also fine. It doesn't matter to you, either way.

Your logic is wrong, though. The NSString object is not "within" myObject; they are just two separate objects, with separate memory management. Maybe myObject has a pointer to the string (in which case it is surely retained by myObject until myObject is released), or maybe it generates the string on the fly (in which case it will be autoreleased). In either case, what you do to the object -- retain, release, or autorelease it -- will not affect the string. What is important is that you retain the string if you want to make sure it stays around (for example, even after myObject is collected). Classes like NSTextField of course retain the strings they want to make sure stay around, so only worry about your own code, not other people's.

Unlike what tobli said, you should not release the myObject unless you previously retained it (which you should probably do unless it is only being used within a single scope). Releasing an object with a reference count of 0 will cause an error (maybe not fatal, but it will at least make an ugly log entry).

[ 12-06-2001: Message edited by: tie ]
The 4 o'clock train will be a bus.
It will depart at 20 minutes to 5.
     
Professional Poster
Join Date: Oct 2001
Location: London
Status: Offline
Reply With Quote
Dec 6, 2001, 06:29 PM
 
Thanks very much guys, most helpful and clear.
     
   
Thread Tools
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Top
Privacy Policy
All times are GMT -5. The time now is 02:59 PM.
All contents of these forums © 1995-2011 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.7 © 2000-2011, Jelsoft Enterprises Ltd., Content Relevant URLs by vBSEO 3.3.2