Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: Clark Cox <email@hidden>
- Date: Sun, 28 Jun 2009 17:35:23 -0700
On Sun, Jun 28, 2009 at 4:32 PM, Quincey
Morris<email@hidden> wrote:
> On Jun 28, 2009, at 16:12, Michael Ash wrote:
>
>> Your way sounds sensible, but according to the docs that's not how it is.
>
> We'll have to wait for b.bum to adjudicate, since the docs contradict what
> he said earlier:
>
> On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarner<email@hidden> wrote:
>>
>> When a CF object is created, it is CFRetain()ed and, thus, the collector
>> will ignore it. If it is then managed entirely through a balanced set of
>> CFRelease() and CFRetain() calls, it'll work just like it does under
>> non-GC.
>>
>> If you call CFMakeCollectable(), that'll effectively balance the
>> CFRetain()
>> at creation while making the collector aware of the object.
>
> His "just like it does" strongly implies that the memory is disposed of
> immediately, unless he meant "just like it does under non-GC, except for the
> timing of disposal".
>
> His "making the collector aware of the object" contradicts the docs, since
> that would be a third thing CFMakeCollectable does.
>
> Of course, it might work the way the docs say in Leopard, and possibly Bill
> was talking about possible future behavior in some possible future Mac OS X.
The collector is always "aware" of CF objects in the same way as it is
aware of Objective-C objects. The difference is that the retain count
that CFRetain/CFRelease manage is still honored under GC. An object
with a non-zero CF retain count is not eligible for collection,
regardless of whether or not there are any other strong references to
it. This allows CF-using code to work under GC, in much the same way
as it does under retain/release.
Under garbage collection, CFMakeCollectable (and NSMakeCollectable) is
simply an alias for CFRelease, but with an better, more
intention-revealing name. Under retain/release on the other hand,
CF/NSMakeCollectable is a no-op.
This fact can also be used in the other direction. If you have an
Objective-C object that you want to stick around, even if there are no
strong references to it (e.g. if you want to store it in a void*,
perhaps to pass as a callback parameter, or if you want to store it in
an STL container), you can CFRetain it, and the collector will know
that it is a live object, effectively rooting it, until a
corresponding CFRelease (or CFMakeCollectable) decreases its CF-retain
count to zero.
>From the collector's point of view, there is no difference between an
Objective-C object, and a CFType object with a zero retain count.
--
Clark S. Cox III
email@hidden
_______________________________________________
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