Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why the rules concerning release?

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.



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.