Re: Releasing what's in an array?
Re: Releasing what's in an array?
- Subject: Re: Releasing what's in an array?
- From: Bob Ippolito <email@hidden>
- Date: Fri, 25 Feb 2005 14:27:27 -0500
On Feb 25, 2005, at 2:20 PM, Mark Dawson wrote:
You must have missed my other email... but when the array is
_dealloced_ it will send a release message to all objects that it
contains before it itself is dealloced. If it didn't it would break
with the expect memory contract when using Cocoa (in a nut shell
"release what you retained or allocated (i.e. implicit retain) when
you are done with it").
Does this mean that you have to do extra work if you release an array
with objects that should NOT be released by you (i.e., objects you did
NOT allocate)? A "more work" case would be an array of strings, some
of which you allocated (and thus you should release), and some of
which you got via getters (ones that you don't release). With
something like that, would you have to keep track of what was
allocated and what wasn't? Then iterate through the array, increasing
the retain count for those that shouldn't be released (thus having
leaving the retain count what it should be, after NSArray's dealloc
releases everything)?
No. You're thinking too hard. The reference counting conventions are
very simple, and they work, because everything balances out.
You only have to worry about sending release or autorelease messages to
objects that you sent a retain message to (possibly implicitly with
something like alloc, copy, etc.). All of the Foundation containers
(and hopefully nearly all other code you run into) should follow this
convention, so when an object isn't used any more, its retain count
will return to 0, and it will be dealloc'ed.
-bob
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden