Heisenbug involving Destructors & GC - Help Needed

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 30 06:02:07 PDT 2015


On 6/26/15 11:38 PM, Brian Schott wrote:
> On Saturday, 27 June 2015 at 03:16:35 UTC, rsw0x wrote:
>> calling destroy on a pointer should either be fixed or be an error,
>> that should not be allowed to happen.
>
> Completely agreed. Calling destroy() on a pointer has been incorrect
> EVERY time I've seen it done.

I'd say if you want to see cases where it was done correctly, change the 
behavior and watch the complaints come in ;)

Wouldn't destroying the pointer target make an assumption about ownership?

Consider a struct that contains a pointer:

struct S
{
    T *x;
}

destroy's algorithm for this struct is to call destroy on all of the 
members, then set to S.init. But what if S is just *referencing* that T, 
and doesn't *own* it? Isn't this the wrong thing to do?

I agree it's inconsistent with class references. How to make it 
consistent isn't as easy to decide. For me, it's the class destruction 
which is incorrect. Consider that destroy is consistent with scope 
destruction for every type except for classes:

class C {}
struct S {}

{
    C c = new C;
    S s;
    S *s2 = new S;
} // calls s.dtor, does not call c.dtor or s2.dtor

And what about arrays? Should calling destroy on an array call destroy 
on all of the elements (it currently doesn't)?

If I were to design destroy from scratch, I'd make destroy, and 
destroyRef (which destroys referenced data via pointer or class).

-Steve


More information about the Digitalmars-d mailing list