Re: Guidelines for Cocoa frameworks supporting garbage collection?
On 7/5/08 2:56 PM, Chris Hanson said:
For example, this pseudocode is wrong under GC:
- (NSURL *)someURL {
NSURL *URL = (NSURL *)CFURLCreate...(...);
return [URL autorelease];
}
It will leak, because the runtime will eat the -autorelease message
when running under GC.
Which reminds me of something else Bill might want to watch out for:
Apple's leak finding tools ('leaks', Instruments, Malloc Debug) do not
work with GC apps. They report so many false positives that they are
unworkable (except for Malloc Debug, which just crashes). So if your
code uses malloc/new/NewPtr of whatever, you'll have a hard time finding
leaks.
Also, I second the recommendation to stay away from finalize. I've used
it exactly twice: 1) to call DisposeHandle() to 2) to call NSLog.
--
Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
___
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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Jul 5, 2008, at 10:07 PM, Chris Hanson wrote: Can you give an example of a framework method that's documented to return an autoreleased CF object? NSBitmapImageRep: - (CGImageRef)CGImage Returns an autoreleased CGImage object (an opaque type) from the receiver’s current bitmap data. http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSBitmapImageRep_Class/Reference/Reference.html#//apple_ref/occ/instm/NSBitmapImageRep/CGImage mmalc ___ 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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Jul 5, 2008, at 11:04 PM, mmalc crawford wrote: On Jul 5, 2008, at 10:07 PM, Chris Hanson wrote: Can you give an example of a framework method that's documented to return an autoreleased CF object? NSBitmapImageRep: - (CGImageRef)CGImage Returns an autoreleased CGImage object (an opaque type) from the receiver’s current bitmap data. Interesting, thanks for the tip! -- Chris ___ 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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Jul 5, 2008, at 22:07, Chris Hanson wrote: On Jul 5, 2008, at 3:52 PM, Quincey Morris wrote: The other thing worth noting is that, when GC is enabled, any CF object that is documented to be *returned* already autoreleased from a frameworks function is actually returned with a reference count of 1, so you still need to call CFMakeCollectable yourself in that case, even though you wouldn't follow it with a call to autorelease like you would in Chris's examples. I don't believe this is the case. Can you give an example of a framework method that's documented to return an autoreleased CF object? I would assume that the result of such a method has already had CFMakeCollectable called on it, making doing so unnecessary. The example I was thinking of was -[QTMovie frameImageAtTime:withAttributes:error:], which is clearly documented to return autoreleased objects. I know from getting all tangled up in it that with GC on it returns 'CGImageRef's and 'CVPixelBufferRef's with a reference count of 1. The CVPixelBufferRef was a particular trial because CFMakeCollectable isn't allowed on it, and there's no CVMakeCollectable AFAIK. But it may well be true that there are no non-Cocoa functions that return autoreleased objects, only a few Cocoa methods that return autoreleased non-Cocoa objects. 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. ___ 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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 2:04 AM, mmalc crawford at [EMAIL PROTECTED] wrote: On Jul 5, 2008, at 10:07 PM, Chris Hanson wrote: Can you give an example of a framework method that's documented to return an autoreleased CF object? NSBitmapImageRep: NSEvent, too: - (const void *)eventRef -- returns a carbon EventRef opaque type corresponding to the receiver - (CGEventRef)CGEvent -- returns a Core Graphics CGEventRef opaque type corresponding to the receiver The Leopard AppKit release notes say of the first of these The EventRef is retained by the NSEvent, so will be valid as long as the NSEvent is valid, and will be released when the NSEvent is freed. You can use RetainEvent to extend the lifetime of the EventRef, with a corresponding ReleaseEvent when you are done with it. The release notes say of the second: -CGEvent ... Returns an autoreleased CGEventRef corresonding to the NSEvent. If you want to control the lifetime of the CGEventRef, you should retain it. I was puzzled at first by the differing return type conventions, and by the different phrasing of the memory management discussions. I guess, however, from looking briefly at the Carbon Event Manager Reference, that the carbon EventRef isn't a CFType and has a variety of memory management methods of its own -- I've never had occasion to use it. But they seem to present the same issues with respect to their use in a garbage collected Cocoa application or framework. -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 2:45 AM, Quincey Morris at [EMAIL PROTECTED] 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 PROTECTED]
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com
PreFab Software - www.prefabsoftware.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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 1:07 AM, Chris Hanson at [EMAIL PROTECTED] wrote: On Jul 5, 2008, at 3:52 PM, Quincey Morris wrote: The other thing worth noting is that, when GC is enabled, any CF object that is documented to be *returned* already autoreleased from a frameworks function is actually returned with a reference count of 1, so you still need to call CFMakeCollectable yourself in that case, even though you wouldn't follow it with a call to autorelease like you would in Chris's examples. I don't believe this is the case. Can you give an example of a framework method that's documented to return an autoreleased CF object? I would assume that the result of such a method has already had CFMakeCollectable called on it, making doing so unnecessary. I don't question Quincey's experience with -[QTMovie frameImageAtTime:withAttributes:error:], which I haven't looked at. But I agree with Chris as to the NSEvent methods I describe in another post, and the similar methods in my own frameworks. In these cases, when the Cocoa object goes away, its CFType-derived counterpart also goes away. -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-05 6:14 PM, William J. Cheeseman at [EMAIL PROTECTED] wrote:
it would be very helpful to have some good examples of ways to
move cleanup code out of dealloc/finalize and into what you call
deterministic methods.
It occurs to me that this is a question that will eventually be answered by
an evolving Cocoa design pattern, as so many other Cocoa design patterns
have evolved over time.
Apple's garbage collection documentation very strongly advises us not to
implement a -finalize method if at all possible, but instead to do cleanup
in a method whose invocation the developer can control -- in order to avoid
the problems that can be created by the built-in uncertainty as to when
-finalize will be called, not to mention the overhead that would be created
at collection time.
So here's a possible approach that was suggested to me privately, for use in
a framework that supports garbage collection. Comments?
@interface MyFrameworkClass : NSObject {
BOOL wrappedup;
}
- (void)wrapup;
- (void)someMethod;
@end
@implementation MyFrameworkClass
- (void)finalize {
if (!wrappedup) {
// protect against inadvertent early termination
[self wrapup];
}
}
- (void)wrapup {
// cleanup code goes here
wrappedup = YES;
}
- (void)someMethod {
[self wrapup];
}
@end
--
Bill Cheeseman - [EMAIL PROTECTED]
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com
PreFab Software - www.prefabsoftware.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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
Le 6 juil. 08 à 14:45, Bill Cheeseman a écrit : on 2008-07-06 2:45 AM, Quincey Morris at [EMAIL PROTECTED] 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. If __strong is so dangerous, why is it used in Cocoa (see NSDrawer, NSDateFormatter, NSNumberFormatter, NSKeyedArchiver, NSURL, …) ? smime.p7s Description: S/MIME cryptographic signature ___ 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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Sun, Jul 6, 2008 at 5:45 AM, Bill Cheeseman [EMAIL PROTECTED] wrote:
on 2008-07-06 2:45 AM, Quincey Morris at [EMAIL PROTECTED] 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.
If CFRetain/CFRelease are indeed balanced, then you don't need the
__strong keyword *but* this requires that you implement -finalize to
CFRelease your ivars. You should, instead, use __strong, and
CFMakeCollectable, and eliminate the need to implement -finalize.
For example. In option 1 below, the object pointed to by ivar won't
likely be collected until the cycle *after* the MyObject instance is
collected, while in option 2, it is collected as part of the same
cycle. By using option 1, you are causing extra work for the collector
and potentially raising your memory high-water mark.
//Option1:
@interface MyObject : NSObject {
CFTypeRef ivar;
}
-(void)createIvar;
@end
@implementation MyObject
-(void)dealloc {
if(ivar) CFRelease(ivar);
[super dealloc];
}
-(void)finalize {
if(ivar) CFRelease(ivar);
[super finalize];
}
-(void)createIvar {
ivar = CFFooCreateFoo(...);
}
@end
//Option2:
@interface MyObject : NSObject {
__strong CFTypeRef ivar;
}
-(void)createIvar;
@end
@implementation MyObject
-(void)dealloc {
if(ivar) CFRelease(ivar);
[super dealloc];
}
-(void)createIvar {
ivar = CFMakeCollectable(CFFooCreateFoo(...));
}
@end
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.
What additional overhead does he imagine will be incurred?
--
Clark S. Cox III
[EMAIL PROTECTED]
___
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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 9:49 AM, Jean-Daniel Dupas at [EMAIL PROTECTED] wrote: If __strong is so dangerous, why is it used in Cocoa (see NSDrawer, NSDateFormatter, NSNumberFormatter, NSKeyedArchiver, NSURL, ) ? Those are interesting examples, especially NSDrawer. In NSDrawer, only the CFRunLoopTimerRef and CFRunLoopObserverRef iVars are given the __strong keyword, while the CFRunLoopRef iVar is not. This suggests to me that some very refined thinking is going on as to when to use or not to use the __strong keyword. I wish I knew what all the relevant considerations were. In NSURL, the void *_reserved iVar is given the __strong keyword, which doesn't tell us much since _reserved may not be used at all. Ditto NSKeyedArchiver. In NSDateFormatter, a CFDateFormatterRef iVar is given the __strong keyword. This seems consistent with your point, but I am still haunted by the fact that NSDrawer's CFRunLoopRef iVar is not given the __strong keyword. Ditto NSNumberFormatter. -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Sun, Jul 6, 2008 at 11:25 AM, Bill Cheeseman [EMAIL PROTECTED] wrote: on 2008-07-06 9:49 AM, Jean-Daniel Dupas at [EMAIL PROTECTED] wrote: If __strong is so dangerous, why is it used in Cocoa (see NSDrawer, NSDateFormatter, NSNumberFormatter, NSKeyedArchiver, NSURL, Š) ? Those are interesting examples, especially NSDrawer. In NSDrawer, only the CFRunLoopTimerRef and CFRunLoopObserverRef iVars are given the __strong keyword, while the CFRunLoopRef iVar is not. This suggests to me that some very refined thinking is going on as to when to use or not to use the __strong keyword. I wish I knew what all the relevant considerations were. CFRunLoopRefs live for the entire lifetime of their thread, so there's no need for __strong. But I would suggest that, as is the case for many other things, you don't need to duplicate Apple's refined thinking as to whether to use __strong or not. Do you want to keep a reference to a CF object? If yes, use __strong. End of story. You might use __weak if you want a zeroing weak reference. But this is extremely uncommon in a dual-mode framework such as what you're writing, because there's no equivalent to __weak in the non-GC world. Aside from wanting a zeroing weak reference, there's no real reason not to use __strong. The only reason would be for performance, and as we all know, premature optimization is the root of all evil. You *can* leave off the __strong keyword, provided you do your CFRetains and CFReleases properly and implement a -finalize method to clean things up. But this is less efficient, requires more brainpower, and is unnecessary. Mike ___ 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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
Le 6 juil. 08 à 17:35, Michael Ash a écrit : On Sun, Jul 6, 2008 at 11:25 AM, Bill Cheeseman [EMAIL PROTECTED] wrote: on 2008-07-06 9:49 AM, Jean-Daniel Dupas at [EMAIL PROTECTED] wrote: If __strong is so dangerous, why is it used in Cocoa (see NSDrawer, NSDateFormatter, NSNumberFormatter, NSKeyedArchiver, NSURL, Š) ? Those are interesting examples, especially NSDrawer. In NSDrawer, only the CFRunLoopTimerRef and CFRunLoopObserverRef iVars are given the __strong keyword, while the CFRunLoopRef iVar is not. This suggests to me that some very refined thinking is going on as to when to use or not to use the __strong keyword. I wish I knew what all the relevant considerations were. CFRunLoopRefs live for the entire lifetime of their thread, so there's no need for __strong. But I would suggest that, as is the case for many other things, you don't need to duplicate Apple's refined thinking as to whether to use __strong or not. Do you want to keep a reference to a CF object? If yes, use __strong. End of story. You might use __weak if you want a zeroing weak reference. But this is extremely uncommon in a dual-mode framework such as what you're writing, because there's no equivalent to __weak in the non-GC world. Aside from wanting a zeroing weak reference, there's no real reason not to use __strong. The only reason would be for performance, and as we all know, premature optimization is the root of all evil. You *can* leave off the __strong keyword, provided you do your CFRetains and CFReleases properly and implement a -finalize method to clean things up. But this is less efficient, requires more brainpower, and is unnecessary. Mike I think the rule may be: use __strong for retained/copied ivars, and nothing for assigned ivars. There is no equivalent of zeroing ref, but weak ref are really common in Cocoa. For example, delegate are not retain. the Notification center does not retain observers, and the drawer probably does not retain the runloop. smime.p7s Description: S/MIME cryptographic signature ___ 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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Sun, Jul 6, 2008 at 9:05 AM, Jean-Daniel Dupas [EMAIL PROTECTED] wrote: I think the rule may be: use __strong for retained/copied ivars, and nothing for assigned ivars. There is no equivalent of zeroing ref, but weak ref are really common in Cocoa. For example, delegate are not retain. the Notification center does not retain observers, and the drawer probably does not retain the runloop. The reason delegates and observers aren't retained it to avoid retain cycles. In a GC world cycles aren't a problem (cycle with no roots will be collected). As a result ivars to delegates and observers, etc. can (and some do IIRC) use strong references. -Shawn ___ 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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Jul 6, 2008, at 05:45, Bill Cheeseman wrote: 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? No disagreement ... just footnotes: -- #1 Provided you manage memory just like a non-GC app (so don't call CFMakeCollectable). -- #2 Provided you don't depend on any autorelease-related behavior for CF objects (so be careful with those few things that return autoreleased CF objects, and don't cast bridgeable objects over to their NS versions to call 'autorelease') -- #3 Provided you add duplicates of any CFRelease calls inside 'dealloc' methods to the corresponding 'finalize' methods, to avoid leaking those objects. Most likely you've already got #1 covered, possibly #2 won't affect the CF objects you're using, and #3 is easy if you haven't done it already. ___ 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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Jul 6, 2008, at 05:48, Bill Cheeseman wrote:
So here's a possible approach that was suggested to me privately,
for use in
a framework that supports garbage collection. Comments?
@interface MyFrameworkClass : NSObject {
BOOL wrappedup;
}
- (void)wrapup;
- (void)someMethod;
@end
@implementation MyFrameworkClass
- (void)finalize {
if (!wrappedup) {
// protect against inadvertent early termination
[self wrapup];
}
}
- (void)wrapup {
// cleanup code goes here
wrappedup = YES;
}
- (void)someMethod {
[self wrapup];
}
@end
IMO it's either not safe or not necessary.
The purpose of keeping stuff out of finalize is first and foremost
about safety, and only secondarily about timing or collection-time
overhead. Collectable memory that is referred to by an object being
finalized may itself already have been finalized, causing the finalize
to crash.
If it's safe to call 'wrapup' from finalize, you may as well just move
the code into finalize and eliminate the 'wrapup' method as
bureaucratic waste.
If it's not safe to call 'wrapup' from finalize, implementing 'wrapup'
hasn't solved the problem for which it was created.
My experience has been that almost every time I've convinced myself
that it was safe to use a particular collectable object in another's
finalize, I was just plain wrong.
A safer pattern might be to replace the above finalize with:
- (void)finalize {
NSAssert (wrappedup, @I'm sorry, Dave, I can't do that ...);
[super finalize];
}
___
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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 10:50 AM, Clark Cox at [EMAIL PROTECTED] wrote: 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. What additional overhead does he imagine will be incurred? CFMakeCollectable as a no-op in a retain/release environment? Which I'm not sure makes sense. But I am becoming persuaded that your Option #2 is in fact the way to go. (Even though I can avoid the collection time overhead of -finalize by implementing some sort of wrapup system such as I outlined in another message.) -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 11:35 AM, Michael Ash at [EMAIL PROTECTED] wrote: You might use __weak if you want a zeroing weak reference. But this is extremely uncommon in a dual-mode framework such as what you're writing, because there's no equivalent to __weak in the non-GC world. There is a weak retain technique, and I use it in one of my frameworks. It was outlined by Ken Case of OmniGroup many years ago. See www.cocoadev.com/index.pl?WeakReferences. I anticipate that I may use __weak to replace this when my framework is used in a garbage collection environment. -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
on 2008-07-06 1:40 PM, Quincey Morris at [EMAIL PROTECTED] wrote: The purpose of keeping stuff out of finalize is first and foremost about safety, and only secondarily about timing or collection-time overhead. Collectable memory that is referred to by an object being finalized may itself already have been finalized, causing the finalize to crash. OK. I just noticed (in an Apple tutorial on Objective-C 2.0) that NSNotificationCenter observers don't need to be set to nil in GC, so that eliminates one reason to need a -finalize method even apart from all this. -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Sun, Jul 6, 2008 at 12:05 PM, Jean-Daniel Dupas [EMAIL PROTECTED] wrote: Le 6 juil. 08 à 17:35, Michael Ash a écrit : Do you want to keep a reference to a CF object? If yes, use __strong. End of story. You might use __weak if you want a zeroing weak reference. But this is extremely uncommon in a dual-mode framework such as what you're writing, because there's no equivalent to __weak in the non-GC world. Aside from wanting a zeroing weak reference, there's no real reason not to use __strong. The only reason would be for performance, and as we all know, premature optimization is the root of all evil. You *can* leave off the __strong keyword, provided you do your CFRetains and CFReleases properly and implement a -finalize method to clean things up. But this is less efficient, requires more brainpower, and is unnecessary. I think the rule may be: use __strong for retained/copied ivars, and nothing for assigned ivars. If the ivar is an ObjC object, then it's already strong automatically, unless you explicitly specify __weak. If it's a CF reference, then you really ought to use either __strong or __weak. If you use nothing, then you're just setting yourself up to explode if the object is collected. Sure, you can get your retains and releases set up to avoid that, but why bother when you have the collector there? The only reason to not put __strong on a CF ref that you would otherwise be leaving blank would be for speed, and that consideration should always come much later. Mike ___ 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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
My experience has been that almost every time I've convinced myself that it was safe to use a particular collectable object in another's finalize, I was just plain wrong. This has been my experience as well. Because the ordering of finalization is undefined, it will often work anyway, making for difficult to reproduce bugs. I've wasted so much time debugging this that I've just abandoned this idiom as impractical. The people I've talked to supporting this as a tenable idiom make unmaintainable assumptions about encapsulation violations, and inheritance implementation details, e.g. that the receiver, or its superclass, won't change in the future in ways that invalidate their assumptions. The dependencies are incredibly fragile and messaging other objects in finalize is just not worth my time. I never message another object in finalize unless my object being finalized owns a CFRetain on the receiver. 'nuke the entire site from orbit. It's the only way to be sure - Ben ___ 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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Jul 5, 2008, at 14:23, Bill Cheeseman wrote: Here's a specific question: My frameworks contain classes that declare instance variables derived from CFType. For example, CGEventRef and AXUIElementRef. In reading the Instance variables topic in the Core Foundation Variables section of the Garbage Collection Programming Guide, I see the statement, If you declare a Core Foundation structure as an instance variable, the compiler regards it only as an opaque structure pointer, not as an object To indicate that a Core Foundation structure should be treated as a collectable object, you use the __strong keyword. The example given declares a CFType-derived object as an instance variable in the interface part of a class like this: __strong CFDateRef myDate; So, I guess my frameworks should declare ... __strong CGEventRef myEvent; __strong AXUIElementRef myUIElement; ... if I am going to advertise the frameworks as supporting both retain/release and garbage collection. Is that right? Just to emphasize what Chris said: With GC on, the CFRetain/CFRelease really do retain and release the same as with GC off. That *might* suggest the idea that don't need __strong instance variables. However, with GC on (assuming you went ahead and called CFMakeCollectable), the __strong instance variables in effect sorta serve as the replacement for autorelease functionality. So, in dual-mode code, a CF object will typically be kept alive by its reference count, maintained as usual in setter methods. Only after a CFRelease takes the reference count from 1 to 0 does the __strong reference matter: it will keep the object from (potentially) disappearing at once. Normally, autorelease has that protective effect. The other thing worth noting is that, when GC is enabled, any CF object that is documented to be *returned* already autoreleased from a frameworks function is actually returned with a reference count of 1, so you still need to call CFMakeCollectable yourself in that case, even though you wouldn't follow it with a call to autorelease like you would in Chris's examples. If I've said anything wrong here, I'm sure Chris will jump in and correct me. :) ___ 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 [EMAIL PROTECTED]
Re: Guidelines for Cocoa frameworks supporting garbage collection?
On Jul 5, 2008, at 3:52 PM, Quincey Morris wrote: The other thing worth noting is that, when GC is enabled, any CF object that is documented to be *returned* already autoreleased from a frameworks function is actually returned with a reference count of 1, so you still need to call CFMakeCollectable yourself in that case, even though you wouldn't follow it with a call to autorelease like you would in Chris's examples. I don't believe this is the case. Can you give an example of a framework method that's documented to return an autoreleased CF object? I would assume that the result of such a method has already had CFMakeCollectable called on it, making doing so unnecessary. -- Chris ___ 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 [EMAIL PROTECTED]
