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