• Russ Lewis (16/16) Nov 20 2006 People, including me, have asked before that Walter add hooks that would...
• genie (5/5) Nov 20 2006 I tried ref counting and it worked quite well. One thing puzzled me,
• Bill Baxter (6/11) Nov 20 2006 Read what the attributes actually mean here:
• genie (3/3) Nov 20 2006 Thanks - which means that whatever is defined outside the module only
• Walter Bright (7/10) Nov 20 2006 You have to be able to overload assignment to get automated refcounting....

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

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?

genie <sgenie maxnet.co.nz> writes:

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?

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

genie <sgenie maxnet.co.nz> writes:

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.

Walter Bright <newshound digitalmars.com> writes:

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).