Re: ivar access during -finalize
Re: ivar access during -finalize
- Subject: Re: ivar access during -finalize
- From: Eric Wing <email@hidden>
- Date: Sat, 10 Mar 2012 23:18:38 -0800
On 3/10/12, Quincey Morris <email@hidden> wrote:
> On Mar 10, 2012, at 17:08 , email@hidden wrote:
>
>> On 10 Mar 2012, at 22:51, Eric Wing wrote:
>>
>>> Just another angle on your original problem, have you considered using
>>> CFRetain and CFRelease on _myIvar? These are still meaningful in
>>> garbage collection mode. Using CFRetain when you get/create _myIvar,
>>> it would presumably still be alive in your finalize method until you
>>> call CFRelease on it.
>>>
>> That sounds like an inspired piece of thinking!
>
> Hold hard, it's not that easy!
>
> Not unless you're incredibly lucky, it isn't. If you CFRetain the ivar
> object, you leave yourself wide open to the problem of retain cycles, the
> normal lack of which is a main benefit of using GC (and the only one left,
> if you consider the alternative of ARC for a new project).
>
> If you can *prove* there are no reference cycles involving the original
> object and the ivar object, then this approach will work fine. But how do
> you prove that? The frameworks introduce lots and lots of references you're
> not normally aware of, and reference cycles appear in surprising ways.
>
I don't disagree that finalizers are hard and need to be approached
with great care. And I agree that all 4 of your points are valid.
However, I think this description of the retain cycle problem might be
a little over-dramatic. Retain cycles have always been a problem in
classic memory management and are still a problem even under ARC. Yet
there is over a decade's worth of code that managed to write code to
the Cocoa framework and for the most part avoid retain cycles. With a
simple scoped problem, well defined strategy, and some care, I think
this is entirely doable. And if he were to go manual management or
ARC, he has to avoid retain cycles anyway so he still has to design
carefully.
Also, this CFRetain/CFRelease pattern isn't unheard of. I see it used
typically in projects that use C++ with Obj-C (often the C++ is for a
cross-platform code base). Sometimes these frameworks try to support
dual mode or sometimes directly use GC in which case they start doing
the CFRetain/CFRelease chicken dance.
-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
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