Re: Guidelines for Cocoa frameworks supporting garbage collection?
Re: Guidelines for Cocoa frameworks supporting garbage collection?
- Subject: Re: Guidelines for Cocoa frameworks supporting garbage collection?
- From: Bill Cheeseman <email@hidden>
- Date: Sun, 06 Jul 2008 08:45:47 -0400
- Thread-topic: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 2:45 AM, Quincey Morris at email@hidden wrote:
> It also occurs to me that the OP is going to have to be careful to
> document the behavior of methods in *his* framework that return new CF
> objects (if there are any). He'll have to decide whether to use CF
> rules (retain count == 1), Cocoa rules (retain count == 1 or
> autoreleased object, depending on whether the caller or the framework
> is regarded as the owner of the new object), or to return an object on
> which CFMakeCollectable has already been called.
Actually, I (the OP) am receiving inconsistent advice privately regarding
the original question (the OQ?), namely, whether to use the __strong keyword
when declaring an instance variable with a CFType-derived type. Privately, I
have been told by a knowledgeable developer that I do NOT need to use
__strong, if I have been careful in my framework to balance my calls to
CFRetain and CFRelease. He even goes so far as to suggest that it would be
dangerous or at least inefficient to use __strong in a mixed environment
such as a shared framework that supports both garbage collection and
retain/release, due in part to the additional overhead.
In fact, my framework does balance CFRetain and CFRelease, because my
framework is also usable in a retain/release client application. My
documentation for the accessor method in my PFUIElement class, for example,
reads like this:
- (AXUIElementRef)elementRef {
// Returns the accessibility API AXUIElementRef object that was
associated with the receiver when the receiver was created. It is CFRetained
and will automatically be CFReleased when the UI element it represents is
destroyed. If you CFRetain it yourself to keep it around, you must CFRelease
it when you're done with it.
return elementRef;
}
I wrote this back in Tiger days, before the similar NSEvent methods were
public. If I'm reading between the lines correctly, I lucked into exactly
the same memory management behavior that NSEvent now implements. But I
confess that the NSEvent documentation isn't altogether clear to me.
So, back to the OQ. I am now inclined to think that, at least in my
circumstances (a shared framework properly balancing CFRetain and
CFRelease), I do NOT need to use the __strong keyword for the CFType-derived
instance variables, in order to support garbage collection. Any
disagreement?
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com
PreFab Software - www.prefabsoftware.com
_______________________________________________
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