Re: NSEnumerator behaves unexpectedly
Re: NSEnumerator behaves unexpectedly
- Subject: Re: NSEnumerator behaves unexpectedly
- From: Charlton Wilbur <email@hidden>
- Date: Sun, 5 Nov 2006 13:23:30 -0500
On Nov 5, 2006, at 1:03 PM, Hans van der Meer wrote:
In the next code fragment three objects are created and added to an
array. I expect them to have retain count 2 after insertion in the
array and that is indeed the case.
Then I did an enumeration over the array, and lo and behold, the
last item got an increased retain count. This increased retain
count turns out to persist until the next cycle in the
autoreleasepool.
The framework can do whatever the heck it wants with retains and
releases, so long as they're balanced. If it wants to pick a random
number between 0 and 50 and issue that many retains and that many
autoreleases before handing you the object, it's perfectly free to do
so. Retain counts are not a useful debugging tool for that reason,
because the framework has that freedom. They also don't indicate
memory leaks, because they do not account for delayed release messages.
The bug here is not in the library, but in that you expect the retain
count to be meaningful.
In this case, the additional retain count for the last element in the
collection is a safeguard -- if the array should be released at the
end of the iteration, the additional retain/autorelease messages that
NSEnumerator sends to the last object means it won't unexpectedly go
out of scope.
Charlton
--
Charlton Wilbur
email@hidden
_______________________________________________
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