VilemKurz/ShareKit — comment on commit e8845fae28c8daf8166a5540a82393139b780b72
File:  line 0
By troppoli:

In this case, if you put a breakpoint in dealloc, it will be called during release as the ref count will reach zero. When control returns from release if you were to use any members of self, they would have been released in dealloc so there would be trouble.

If a subclass had overridden this method and called super first, there might be trouble, unless it avoided members or retained before calling super.

Calling auto release instead, waits to call release (and therefore dealloc in this case because the retain count reaches zero) until the current auto release pool goes out of scope. This happens when the current event finishes processing and control returns to IOS.

Like I said, there's not any trouble in this case and anyone that expects the object to be retained should retain it... But when you might effectively be calling dealloc on an object from within one of its members I'd prefer an auto release.

One way to see a little more about what is going on is a little debugging trick... Override retain, release and autoRelease and in each of them put a breakpoint and log the retainCount.

-s

On Jan 21, 2012, at 3:03 AM, Vilém Kurz wrote:

> I always thought that the release means that **I** do not need it anymore, but it is not deallocated until it is out of scope. Can you explain the specific issue? I also did not understand "take care not to touch and members ect". Sorry for so many questions about such trivial issue, but I am eager to learn something new.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/VilemKurz/ShareKit/commit/e8845fae28c8daf8166a5540a82393139b780b72#commitcomment-888125