Thread overview
Mixins for GC-Flexibility?
Nov 21, 2006
Russ Lewis
Nov 21, 2006
genie
Nov 21, 2006
Bill Baxter
Nov 21, 2006
genie
Nov 21, 2006
Walter Bright
November 21, 2006
People, including me, have asked before that Walter add hooks that would enable refcounting collectors.  This requires hooks, at least, which are called when a reference is first initialized, when it is modified, and when it is destroyed.

Walter has responded that it is impractical to add these, one reason being the runtime overhead of calling these hooks.  (Sorry, Walter, if I've forgotten other reasons.)

What if the compiler inserted a mixin, defined in object.d, to each such event?  In the default library, that mixin would be empty, incurring zero runtime cost.  In alternate collectors, it could be non-empty, and would insert actions without the requirement of calling a library function.

Obviously, this would mean that you would have to make a compile-time decision which library you are going to link to, but I would be very surprised if we weren't required to do that already.  Ofc, if you really valued runtime plugability, then your mixin could call a pluggable function.

Thoughts?
November 21, 2006
I tried ref counting and it worked quite well. One thing puzzled me, however - when I declared a destructor for a class to be protected, I could still call delete on an object of this class - something that you can't do in C++ - is it the expected behaviour of D or just a bug in the compiler?
November 21, 2006
genie wrote:
> I tried ref counting and it worked quite well. One thing puzzled me,
> however - when I declared a destructor for a class to be protected, I
> could still call delete on an object of this class - something that
> you can't do in C++ - is it the expected behaviour of D or just a bug
> in the compiler?

Read what the attributes actually mean here:
http://www.digitalmars.com/d/attribute.html#deprecated

In particular, everything in a module acts like a 'friend' with everything else in that module.

--bb
November 21, 2006
Russ Lewis wrote:
> Walter has responded that it is impractical to add these, one reason being the runtime overhead of calling these hooks.  (Sorry, Walter, if I've forgotten other reasons.)

You have to be able to overload assignment to get automated refcounting. Plus a bunch of complexity has to be added to the compiler to be able to unwind the refcounting if, say, one of the function parameters throws before the function gets called. It's uuugly.

If you want refcounting, the easiest way to do it is to do it manually by making a COM class (addref and release).
November 21, 2006
Thanks - which means that whatever is defined outside the module only
cannot use delete() on the objects (provided dtor is private) but
have to use Release() - OK, got it.