Re: Autorelease pool questions
Re: Autorelease pool questions
- Subject: Re: Autorelease pool questions
- From: Nicholas Riley <email@hidden>
- Date: Sun, 19 Jan 2003 12:34:43 -0600
- Mail-followup-to: Brian Gilman <email@hidden>, Cocoa Dev <email@hidden>
On Sun, Jan 19, 2003 at 01:01:23PM -0500, 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??
No. The runtime does not automatically 'clean up' pointers to
deallocated objects, so if you aren't careful you can be sending
messages to garbage or to objects of another class. You're not using
references (&var in a C++ declaration), these are real pointers to
memory locations with the associated lack of safety. Setting
NSZombieEnabled helps identify these situations by replacing the class
of a deallocated object with a 'zombie' that complains if it's
messaged.
>
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.
The latter, of course. There are no 'clean up cycles' (e.g. garbage
collection passes) in Cocoa; it's relatively determininstic when each
object deallocation occurs. I'm sure several of those articles you
were pointed out say this, but just to underscore it:
- alloc, retain - increment object's retainCount
- release - decrement object's retainCount
- autorelease - decrement object's retainCount at some point in the
future
- convenience constructors (fooWithBar:), accessors - return objects
which you must retain, to guarantee they stay around once the flow
of control leaves your code (generally function return) or the scope
of the current autorelease pool
You're welcome to examine an object's retain count - just send any
NSObject the 'retainCount' message and you'll get back a number.
OmniObjectMeter will show you the entire retain/release/autorelease
history of an object, and if you can explain exactly why each event
happens, then you understand Cocoa memory management rules pretty
well.
>
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.
No. Autorelease pools do not manage memory allocation; they don't
bound the scope of objects which they hold. They simply hold lists to
which object pointers are added when the objects are sent
-autorelease, and which send -release to each object in the list when
they are deallocated.
>
Grrr....I think I need to read more.....
Yes, generally better to do that before posting half-formed thoughts
on a mailing list read by thousands of people. :)
--
=Nicholas Riley <email@hidden> | <
http://www.uiuc.edu/ph/www/njriley>
Pablo Research Group, Department of Computer Science and
Medical Scholars Program, University of Illinois at Urbana-Champaign
_______________________________________________
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.