Michel Fortin wrote:
Le 27-juin-2013 à 15:32, Walter Bright a écrit :
> On 6/27/2013 11:38 AM, Michel Fortin wrote:
>>> 14. RC objects will still be allocated on the GC heap - this means that a
normal
>>> GC run will reap RC objects that are in a cycle, and RC objects will get
automatically
>>> scanned for heap references with no additional action required by the user.
>> If you allocate the object from the GC heap, the GC will collect it
regardless of its reference count. That's fine as long as all the retaining
pointers are visible to the GC. But if you're defining a COM object, likely
that's because you'll pass a pointer to an external API, and this API might
store the pointer somewhere not scanned by the GC. This API will call AddRef to
make sure the object is retained, but if the GC doesn't see that pointer on its
heap it'll deallocate and next time external code uses the object everything
goes boom! So that doesn't work.
>
> We already require that if you're going to pass a pointer to any GC allocated
data to external code, that you retain a pointer. I see no additional issue with
requiring this for COM objects created on the GC heap.
Perhaps it's just me, but I'd say if you need to anticipate the duration for
which you need to keep the object alive when you pass it to some external code
it completely defeats the purpose of said external code calling AddRef and Release.
With the scheme you propose, reference counting would be useful inside D code as
a way to deallocate some classes of objects early without waiting a GC scan. The
GC can collect cycles for those objects.
People passing COM objects to external code however should allocate those
objects outside of the GC if they intend to pass the object to external code.
They should also add member pointers as GC roots. Also, no cycle detection for
those objects. If done right it could be made memory safe, but cycles will leak.
Maybe that could work.
