Re: Why the rules concerning release?
Re: Why the rules concerning release?
- Subject: Re: Why the rules concerning release?
- From: Shawn Erickson <email@hidden>
- Date: Sat, 31 Jul 2004 17:45:26 -0700
On Jul 31, 2004, at 4:49 PM, Mark Patterson wrote:
Hi,
I'm trying to get into Obj-C after years in Delphi, so I need to get
the new object model clear. Much is similar, but the object life-cycle
stuff is confusing. Hillegass say:
* Objects created by alloc or copy have a retain count of 1 and are
NOT in the autorelease pool
* Objects obtained any other way have a retain count of 1 and are in
the autorelease pool.
Can someone explain the thinking behind this. Is there a good reason
or a historical reason for this duality? It might be nice of alloc and
copy autoreleased their objects as well, for consistency. Why is that
not done?
Humm... those two points outline the end result of the Cocoa memory
management policy not the why very well... I think that is what is
confusing you.
In Cocoa a memory management contract is defined to simplify reference
count based memory management. If you create an object (alloc, copy,
mutableCopy, etc.) then you are responsible to balance the implicit
retain all objects have initially (that retain count of one talked
about).
So if you create an object do something with and then don't want it any
longer (assuming no other retains have been sent to it) you simply send
it a release message and away it goes away.
Now what if you want to give an object that you created to someone
else? How do you live up to the contract of balancing the implicit
retain since you (you = a block of code) created the object without
having the object disappear before the others can get a hold of it?
The answer is to send the object a delayed release message and then
pass the object off to that someone else with the goal of giving the
that someone else a chance to use/retain the object. A delayed release
message is sent by adding the object to the current autorelease pool
which is done by sending the object an autorelease message. So this in
effect queues up the sending of a release message to the object (one
release will be sent for autorelease message sent), allowing it to
continue to exist temporarily until such time as the it can be
used/retained by someone else.
When an autorelease pool is deallocated all of the those "queued up"
release messages will be sent. In an NSApplication base application an
autorelease pool is created and deallocated every event cycle by
default (you and others can create their own as needed to bound memory
usage, etc.)
Anyway see the following documentation on this...
<
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/
index.html>
-Shawn
_______________________________________________
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.