On Sun, Jun 28, 2009 at 1:17 PM, Quincey Morris<quinceymor...@earthlink.net> wrote: > I think the answer is in Bill's "entirely", above. > > Without CFMakeCollectable, the final CFRetain will trigger the calling of (a > hypothetical) CFDispose with the traditional timing (i.e. immediately, we > assume, somewhat at our peril). > > After CFMakeCollectable in a GC-enabled environment, the final CFRetain (if > there is one, if the retain count was greater than 1 at the time > CFMakeCollectable was called) will just discard *the* strong reference that > the retain count was maintaining. This will trigger the calling of (a > hypothetical) CFFinalize with the usual timing (i.e. when the collector > runs, after there are no other strong references remaining). > > Thus GC-unaware code gets the behavior at CFRelease time that it expects > (somewhat at its peril), whether or not it is running in a GC-enabled > environment.
"If the object is in the garbage collected zone, the last CFRelease() does not immediately free the object, it simply makes it eligible to be reclaimed by the collector when it is discovered to be unreachable—that is, once all strong references to it are gone. Thus as long as the object is still referenced from an object-type instance variable (that hasn't been marked as__weak), a register, the stack, or a global variable, it will not be collected." >From the Garbage Collection Programming guide. Your way sounds sensible, but according to the docs that's not how it is. 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 arch...@mail-archive.com
