draft proposal for ref counting in D

Walter Bright newshound2 at digitalmars.com
Wed Oct 9 19:26:40 PDT 2013


Steven Schveighoffer wrote:

On Jun 30, 2013, at 6:11 PM, Walter Bright wrote:

 >
 > On 6/30/2013 3:05 PM, Michel Fortin wrote:
 >> Le 2013-06-30 à 16:32, Walter Bright  a écrit :
 >>
 >>> Amended as:
 >>>
 >>> 6. If a class or struct contains RC fields, calls to Release() for those 
fields will
 >>> be added to the destructor, and a destructor will be created if one doesn't 
exist already.
 >>> Release() implementations should take care to not destroy objects that are 
already destroyed,
 >>> which can happen if the objects are allocated on the GC heap and the GC 
removes a cycle of
 >>> refcounted objects.
 >> Good advice. But... how do you implement that? For one thing, I doubt 
there's an API in the GC you can query for deleted objects, and if there was 
it'd be inefficient to call it for every call to Release. And also, will a 
virtual call to a function of a destroyed object work in the first place? It all 
seems quite fragile to me.
 >>
 >
 > The GC doesn't actually delete anything while it is doing a collection cycle. 
So the refcount could simply be checked.

AFAIK, this isn't a requirement of the GC.  May want to add it.  I have bad 
experiences with trying to second guess the GC and when it actually kills the 
object.

Note, if this is the case, then inc/dec refcount cannot depend on vtable, since 
that is zeroed.  I'm wondering if the GC shouldn't set the RC to size_t.max when 
destructing, or even just +1 it, to ensure the ref count destructor doesn't 
accidentally free it before the reaper does.

-Steve


More information about the Digitalmars-d mailing list