Re: Autorelease pool questions
Re: Autorelease pool questions
- Subject: Re: Autorelease pool questions
- From: j o a r <email@hidden>
- Date: Sun, 19 Jan 2003 19:51:43 +0100
Contrary to fully automatic garbage collection, like in Java, Obj-C
uses "semi-automatic" reference counting. Every object has a reference
counter that is initiated to 1 when the object is allocated. Whenever
some piece of your code wants to hang on to some object it should
retain it, that is increasing it's reference count by 1, and when it's
no longer interested in using the object it should release it, that is
decreasing it's reference count by 1. Nothing strange or magical
happening here. When an object's reference count reaches 0 (this
condition is checked every time an object is released) it will
immediately be deallocated.
When a factory method is creating objects for other objects it's not up
to the factory method to retain the newly created object - it's the
receiver of the created object that is interested in the object it
requested from the factory method. Thus, the factory method needs to
hand over the new object to the receiver with an effective retain count
of 0 - or else it would never reach 0 and never ever be deallocated.
That said, how should the factory method hand over the new object to
the object that requested it? It cannot just plain release it, because
it would immediately be deallocated - this is where autorelease comes
into play. If the factory method hands over an autoreleased object it
knows that the receiver will have time to retain it, if it is
interested in keeping it. Problem solved.
Autoreleased objects are not "temporary", or any different from any
other Obj-C objects, it's just that they are referenced from an
autorelease pool and will, at some point in the future when the
autorelease pool is released, be sent a release message.
Think of an autorelease pool like an array, it stores pointers to
objects. When the autorelease pool is released, it will in turn send a
release message to all it's contained objects.
The only thing that is slightly magical about using autorelease pools
is that they are nested, that is all objects that are autoreleased will
end up in the current innermost autorelease pool.
Like Nicholas said. Read some more, play with logging the "retainCount"
of some objects in a test application, and I bet that you'll get the
hang of memory management in Obj-C in no time at all. Like so many
other things it's really easy once you get learn the basics and have a
chance to play with it a bit.
j o a r
On Sunday, Jan 19, 2003, at 19:01 Europe/Stockholm, Brian Gilman wrote:
If all objects are getting placed in this autorelease pool, and
the pool
get's released before I return my object out of this method, am I not
sending back a reference to a null object?? Or, because I tell the
runtime
to retain the temporaryObject, this object's reference count is set to
1 and
not collected on the next clean up cycle?? I may not be using the right
terminology here because I'm new to this stuff so please stick with me
on
this.
I'm thinking that an NSAutoReleasePool is something like a
parameterized
vector that I temporarily stuff objects into. When I use the statement:
NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc]
init];
I'm hinting to the compiler that the objects that I'm about to use
are
temporary. Somehow the obj-c runtime sets up a temp memory area for me
and
starts allocation memory out of there. And that if I use a autorelease
pool
I can tell the pool to retain some of these objects and clean up
others.
_______________________________________________
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.