Re: Releasing Objects
Re: Releasing Objects
- Subject: Re: Releasing Objects
- From: Greg Guerin <email@hidden>
- Date: Wed, 23 Dec 2009 11:01:17 -0700
Michael Craig wrote:
If I'm missing some key concept here, just point me in the right
direction
and I'll go learn it. If it's something more specific, fill me in!
In ownership terms, you released the object, so you no longer own
it. References to it after that point are illegal, even if the
object still exists because it's owned elsewhere.
In allocation terms, the instant an object is deallocated, it is no
longer a valid object. This does not mean that every reference to
it, via its id, will now cause a runtime error. There are practical
reasons for doing this, even though it may deviate from a desirable
ideal.
On the practical level, the memory reclaimed from a deallocated
object is not zeroed, filled, marked, or otherwise altered, except as
needed by the free-space management code. Freed memory may be reused
as other objects are created, so any dangling id from the dead object
is no longer an id, but a dangling C pointer: a dangerous thing with
unspecified behavior.
Your first premise was that an object's retain-count goes to zero,
then it's deallocated. In short, you assume there is a brief
interval when a valid object has a retain-count of zero, right before
it winks out of existence as an object. Logically, however, this is
unnecessary. With a retain-count of 1, the release code knows with
certainty that the object's memory will be freed, so writing anything
to that memory, such as 0 to the retain-count, is unnecessary. If
something is unnecessary and executed frequently, it should be
eliminated.
Your other premise was that a deallocated object will instantly
trigger runtime errors when further messaged. That may be an ideal,
but it's definitely not how the real runtime works. Better still,
what if it's impossible to even have a reference to an invalid
object: if you have an id, it exists. That's what GC tries to
provide, though it still isn't ideal.
-- GG
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden