Re: More memory allocation questions
Re: More memory allocation questions
- Subject: Re: More memory allocation questions
- From: Terry Simons <email@hidden>
- Date: Sun, 28 Jul 2002 19:07:08 -0600
At the end of the event loop,
Sort of yes, but only because of the above, and only if you don't have
any nested pools. It is not a general feature of autorelease pools,
just that Cocoa sets up some autorelease pools that way.
Right, I wasn't thinking about that, but the stepwise docs talk about
nested pools, and setting up your own pools.
I was thinking in the more general sense the allocation pool that is set
up for you with the "standard" apps that I've been working with.
so that if they are in the autorelease pool when you get access to
them, you can make sure they stay around until you're done with them.
This has nothing to do with autorelease pools. Please don't make it
more complicated than necessary.
You want to keep it, you send it retain. That's it.
Right. I should have something more like... "Sending a retain or a copy
guarantees that the object will be around for you until you release it,
unless someone mistakenly sends more release or autorelease messages
than they should to the object."
The allocation pools are *only* used by autorelease, right?
I'm trying to keep it simple, but I'd like to understand the details. :)
If you retain an object, then you should release/autorelease it.
You should release it at some time. (Autoreleasing is nothing more
than releasing a little later).
Right, but the autorelease mechanism deals with allocation pools,
whereas release directly fiddles with the counter, and once it hits 0,
the object gets dealloc'd.
Autorelease does nothing other than put the object in the pool, and that
object eventually gets sent a release.
The thing to care about is that the object will eventually get it's
counter decremented, in the hopes that everyone did everything
correctly, and the counter will hit zero, and be deallocated.
For all intents and purposes it's enough to know that your object "will
be released at a future date".
It seems that you should always use autorelease,
No.
unless you are 100% certain that nobody else is using a specified
object, then release may be preferable because it will free up
resources immediately.
No. If someone else is using that object, they should have retained
it. Autorellease doesn't come into play. There are two levels that
are getting mixed up here:
Level 1:
retain / releave -> dealloc
Level 2:
autorelease -> a later release
The first level turns a global problem (when can this object be
deallocated / when does it have no more references ) into a local one
( do *I* reference this object ).
The second level deals with the "transfer ownership to another object
without losing the object in transit"-problem.
If you don't alloc/init an object, you shouldn't release it.
If you don't: +alloc, -copy, -retain an object. -init doesn't play a
part.
Yeah, I guess I paired them together because I always see [[obj alloc]
init]
If you don't autorelease/release objects that you create with
alloc/init then you'll leak memory.
If you don't release. Autorelease is just a release that happens later.
Yes... but both release and autorelease eventually end up doing the same
thing.
My point was that you need to make sure to release or autorelease when
you've done an alloc, copy, or retain (and someone mentioned +new, which
is depreciated). I happened to skip the copy, and retain, but I
understand what they do, I think. ;) (famous last words)
An autorelease is just an eventual release, but it serves the same
purpose in a broad scope. An autorelease just happens "later" and all
we really care about is that we released our dominance over the object
so to speak.
The one example that keeps floating through my mind is the one where you
might want to return an object that you've created, and so you use an
autorelease in that case, as opposed to a release, because if you simply
release it, then it will be invalidated before the user can retain it.
I appreciate the clarifications and corrections,
- Terry
_______________________________________________
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.