Sure, I get reference counted memory and it could very well be true that Cocoa
has no intent on releasing this at anytime I could expect and that was its
design.
If that's true when I would ask WHEN will it be deallocated? I'm leaking memory
like crazy allocating these objects and would argue it's bad design on Cocoas
part to not give the programmer a reliable way to know when it's memory will be
released, as for example we may need to perform some clean up when the object
is released.
I wonder why Cocoa has retained it 4 times and what it plans to do with it
since I don't see thing that will cause the memory to be released.
Thanks.
On Jul 18, 2011, at 8:07 AM, Peter wrote:
> Maybe I am missing something, but given your example - which in some sense
> contradicts your comment, why do you expect dealloc to be called?
> If the retain count is in fact > 0 after the release (4 in your example
> below) dealloc is not called, since the view can not yet be deallocated.
> View.release just means "*I* (i.e. the caller) don't care about you any
> longer". But if some other object still cares (i.e. the retain count > 0, as
> in your example), dealloc won't be called. In short: release != dealloc. Or
> the other way round: only after x retains are balanced by the same number of
> release messages, dealloc eventually will be called by the runtime and the
> object is finally cleaned up and purged from memory.
>
> Sorry if I am getting you wrong and point out the obvious ...
Regards,
Ryan Joseph
thealchemistguild.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
