Re: A few questions about Memory Management
Re: A few questions about Memory Management
- Subject: Re: A few questions about Memory Management
- From: "Adrian R. Foltyn" <email@hidden>
- Date: Sat, 12 Feb 2005 16:55:29 +0100
Thanks a lot for the clarification, guys. Using the initWith... instead
of the stringWith... method was indeed a mistake of mine and not
intended.
----------------------------------------------------------------
NSString *dreamWorld = [[[NSString
stringWithContentsOfFile:@"/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.
Bob wrote:
Not correct. Read up on NSAutoreleasePool. These objects are indeed
released when the NSAutoreleasePool is popped, there is no memory
leak.
Charlton wrote:
Because none of these methods have +alloc or -copy in their names,
they return autoreleased objects.
John wrote:
Don't forget -mutableCopy, where applicable.
The documentation for NSAutoreleasePool states:
An NSAutoreleasePool object simply contains objects that have received
an autorelease message and when deallocated sends a release message to
each of those objects. An object can be put into the same pool several
times and receives a release message for each time it was put into the
pool. When a thread terminates, it automatically releases all of the
autorelease pools associated with itself.
And NSObject's documentation says:
Note that it’s your responsibility to release objects (with either
release or autorelease) returned by alloc... methods.
Somehow I came to the believe that methods like
stringWithContentsOfFile: actually alloc and init an object for me in
the background according to the parameter given. Well actually it would
have to do some allocating or the object would not exist but it also
adds the object in question to the current NSAutoreleasePool, the pool
sends a release message to the object and so the retain count is 0.
----------------------------------------------------------------
But still i have a problem with this. Let me explain.
Example code:
NSArray *allFileContents = [[NSArray arrayWithObject:[NSString
stringWithContentsOfFile:@"/some/path"]] retain];
Step 1:
NSString instance is created with the method stringWithContentsOfFile:
and has a retain count of 1. Because no alloc, copy or mutableCopy
method was used the instance is added to the autorelease pool. Objects
added to the autorelease pool receive a release message. Thus the
NSString instance has now a retain count of 0.
Step 2:
NSArray instance is created with the method arrayWithObject: and has a
retain count of 1. Because no alloc, copy or mutableCopy method was
used the instance is also added to the autorelease pool and now has a
retain count of 0.
Step 3:
NSString instance is being added to the array thus receiving a retain
message and raising its retain count to 1.
Step 4:
NSArray instance receives a manual retain message and has a retain
count of 1.
Step 5:
The thread ends and sends a release message to the autorelease pool.
Step 6:
The pool sends a release message to each object it contains.
What bothers me now is that the NSString array was created first and so
comes first in the list of objects in the autorelease pool. Either
NSAutoreleasePool is smart enough to handle this or the following
actions would occur:
NSAutoreleasePool sends a release message to the NSString instance
first thus setting the retain count to 0. Then the pool sends a release
message to the NSArray instance and sets its retain count to 0. The
array sends a release message to its member thus setting the retain
count of the NSString instance to -1?
----------------------------------------------------------------
Thank you again,
Adrian
_______________________________________________
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