Destructor nonsense on dlang.org

foobar foo at bar.com
Fri May 25 02:02:15 PDT 2012


On Friday, 25 May 2012 at 07:13:11 UTC, Jacob Carlborg wrote:
> On 2012-05-24 21:46, foobar wrote:
>
>> Looks to me like an issue with separation of concerns. I think 
>> that
>> dtors need to only provide deterministic management of 
>> resources and not
>> affect GC algorithms:
>> 1. classes should *not* have dtors at all.
>> 2. struct values should *not* be gc managed [*].
>>
>> Composition of classes and structs should be handled as 
>> follows:
>> 1. If a class contains a pointer to a struct it doesn't scan 
>> it in a GC
>> cycle. The runtime can provide a hook so that structs could 
>> register a
>> callback for RC purposes.
>> 2. When a class contains a strcut value, they share the same 
>> lifetime
>> thus the GC will call the struct's dtor when the object is 
>> collected.
>
> How is that any different than having destructors for classes.

It makes the call order deterministic like in C++.

e.g.
class Foo {}

struct A {
   resource r;
   ~this() { release(r); }
}

struct B {
   A* a;
   Foo foo;
   ~this() { delete a; } // [1]
}

Lets look at point [1]:
The "foo" instance is "managed" by the GC since the only resource 
it holds is memory. The "a" member wraps some "non-managed" 
resource (e.g. file descriptor) and in this model is still valid, 
thus allows me to deterministically dispose of it as in c++.

This can be simply checked at compile-time - you can only 
reference non class instance members in the destructor, so adding 
a "delete foo;" statement at point [1] simply won't compile.


More information about the Digitalmars-d mailing list