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