Re: Autorelease/Retain/Release
Re: Autorelease/Retain/Release
- Subject: Re: Autorelease/Retain/Release
- From: Charlton Wilbur <email@hidden>
- Date: Tue, 24 Jul 2007 22:01:14 -0400
On Jul 24, 2007, at 9:49 PM, Tim Davis wrote:
Within a given block of code, the number of times you use copy,
alloc and retain should equal the number of times you use release
and autorelease.
You don’t own objects created using convenience constructors (such
as NSString's stringWithString:) or any other accessor method, so
(unless you send them a retain message) you do not have to release
them.
Ok, so I understand the first bullet, and the third and fourth.
But the second bullet has me confused. How do I know what is an
accessor method/convenience method?
The convention is that anything that doesn't have copy or alloc in
its name is a convenience method that gives you something that has
been autoreleased and will go away at some point in the future.
NSSomething *foo = [NSSomething copy];
NSSomething *bar = [[NSSomething alloc] initWithInt: 25];
NSSomething *baz = [NSSomething somethingWithInt: 25];
foo needs to be (auto)released, because it is the result of a copy
call. bar needs to be (auto)released because it is part of the alloc/
init construct. baz does not need to be released because it comes
from a message that doesn't have copy or alloc in its name, and so
the returned value is already autoreleased.
Does this mean that if I don't send the object a [retain] call
during the [[blah alloc] init] statement that I don't need to send
it a [release] later on?
You sent it an alloc message, so you need to send it a release or
autorelease message. If you *also* retained it, you would need to
send it a total of *two* release or autorelease messages.
(The construct NSSomething *quux = [[[NSSomething alloc] initWithInt:
25] autorelease]; is fairly useful in this regard, and you have it in
your code several times.)
Here's my code:
if (![fm fileExistsAtPath: [path stringByAppendingString: @"/
index.xml"]])
{
//Create Minimal XML file for use later.
//Create root element with tag: Root
NSXMLElement *indexRoot = [[[NSXMLElement alloc] initWithName:
@"Root"] autorelease];
[indexRoot addChild: [NSXMLNode elementWithName: @"Namespaces"]];
//Create the document and assign the root element
NSXMLDocument *indexFile = [[[NSXMLDocument alloc]
initWithRootElement: indexRoot] autorelease];
//Grab the raw XML data from the document so we can save it
NSData *xmlData = [indexFile XMLDataWithOptions:
NSXMLNodePrettyPrint];
//Save the data to a file.
[xmlData writeToFile: [path stringByAppendingString: @"/
index.xml"] atomically: YES];
}
else
{
//Load Xml File
}
[pool release];
I created an autorelease pool farther up the awakeFromNib
function. Please look at indexRoot, indexFile, and xmlData. If I
understand this correctly I need to use autorelease on indexRoot
and indexFile because I'm alloc'ing and init'ing? And xmlData is
automagicly destroyed when awakeFromNib exits?
First off, you shouldn't need to create your own autorelease pool in
ordinary circumstances; if you're using the Cocoa event loop, an
autorelease pool is provided for you, and in that case you only need
to create separate autorelease pools if performance is an issue.
That said, you're mostly correct about the retain/release balancing
in the snippet of code -- with the exception that the memory
management contract says that autoreleased objects will go away at
some point in the future. It's possible under this contract that the
autorelease pool will only be emptied when it takes up a certain
amount of memory, or when the moon is new, or alternate Tuesdays at 7
am. Practically speaking, if you're using the Cocoa event loop, it's
emptied at every iteration, but that's a quirk of implementation; if
you're writing a shell tool, for instance, you create your own
autorelease pool and it only empties when you empty it manually.
This is an important distinction, because that indeterminacy can mask
unbalanced retain/release numbers.
Charlton
--
Charlton Wilbur
email@hidden
email@hidden
_______________________________________________
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