Re: A few questions about Memory Management
Re: A few questions about Memory Management
- Subject: Re: A few questions about Memory Management
- From: Charlton Wilbur <email@hidden>
- Date: Fri, 11 Feb 2005 21:31:11 -0500
On Feb 11, 2005, at 8:56 PM, Adrian R. Foltyn wrote:
----------------------------------------------------------------
If I dealloc a NSArray holding other objects that were previously
alloced and inited the objects that were contained in the array are
neither released nor dealloced?
Well, for one thing, *you* don't send the dealloc message. You send
-release, and -dealloc is called if necessary.
When you add an object to a collection, the collection sends it a
-retain method. When you release the collection and dealloc is called,
the collection sends a -release method to all its members.
What you should worry about is making sure that your code sends an
equal number of +alloc/-copy/-retain messages and -release/-autorelease
messages.
----------------------------------------------------------------
If I understood correctly onelinecoding in Cocoa is bad if you care
about how much memory your program uses. As an example:
NSString *dreamWorld = [[[NSString
initWithContentsOfFile:@"/path/to/realWorld.txt"]
componentsSeparatedByString:@"hate"]
componentsJoinedByString:@"love"];
With the above line I will never have the chance to send a release
message to the NSString instance that stores the contents of the file
and the NSArray instance that stores the delimited text as I don't
have any pointers in place that reference to them. Neither the end of
the method this code is executed in nor the deallocation of the object
this method is used in will result in removing the NSString and
NSArray instance from memory.
Well, that line won't work, for one. You'd need [[NSString alloc]
initWithContentsOfFile: @"/path/to/file"] in it to begin with.
The rule is that all calls to +alloc, -copy, and -retain (and methods
including those names) must be balanced with calls to -release or
-autorelease. Once that line is written correctly, you can see that
there's an +alloc message there, and you're right that you'd cause a
memory leak. But -componentsSeparatedByString: doesn't have +alloc or
-copy in it, and so you know that the object you get back from it will
be autoreleased.
So the problem in (the correct version of) your line of code is the
alloc. You're right that there would be a memory leak. But the simple
solution here is to replace the +alloc and -init like so:
NSString *dreamWorld = [[[NSString
stringWithContentsOfFile:@"/path/to/realWorld.txt"]
componentsSeparatedByString:@"hate"] componentsJoinedByString:@"love"];
Because none of these methods have +alloc or -copy in their names, they
return autoreleased objects.
----------------------------------------------------------------
In the documentation for NSArray there is this example code:
NSArray *pathArray = [NSArray arrayWithObjects:@"System", @"Library",
nil];
NSLog("The path is /%@.\n", [pathArray componentsJoinedByString:@"/"]);
Is it impossible to dealloc the resulting NSString instance of the
componentsJoinedByString: call?
You don't need to; it was autoreleased. At some point in the future,
when the autorelease pool is emptied, it will have a -release message
sent to it.
Would it be safe to say that example code in the documentation is not
a good place to study memory management as it tries to demonstrate a
concept in brief?
Well, you need to understand memory management, so I'd focus on that.
I think it is *much* simpler than you expect it to be.
----------------------------------------------------------------
If I would completely ignore memory management while writing a simple
command line tool does the system free the objects in memory after the
tool exits?
What happens to the memory if it crashes?
When the process ends, the system reclaims the memory. This happens
whether it is a normal ending or a crash.
Charlton
--
Charlton Wilbur
email@hidden
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden