On 07/14/2010 10:43 PM, Andrei Alexandrescu wrote:
There is no early failure with dangling pointers.
There is:
class A
{
void foo() {}
}
class B : A
{
override void foo() {}
}
A a = new B;
A a2 = a;
clear(a);
a2.foo();
If you reset the object state to .init, foo will succeed and the program
will happily crawl on. If you zero out the object's memory, the call to
foo will fail. I'd prefer the latter.
The same with an interface:
interface I
{
void foo();
}
class A : I
{
void foo() {}
}
void main()
{
A a = new A;
I i = a;
clear(a);
i.foo(); // would segfault
}
One more (rare but possible):
void bar()
{
}
class A
{
void function() p = &bar;
void foo()
{
p();
}
}
void main()
{
A a = new A;
A a2 = a;
clear(a);
a2.foo; // would segfault
}
I'd probably want clear() to run the destructor and zero the object's
memory.
No, because:
class A
{
int x = -1;
float y = 0;
...
}
You'd want that guy to be obliterated with the proper initializers for x
and y.
Not that I fiercely disagree but ideally I'd want it to be obliterated
to an invalid but easily recognizable state. It might help to discover
dangling pointer errors early. Otherwise, leaving a destroyed object in
a perfectly valid state may make debugging more fun than it needs to be.
In my world, clear() would run the dispose handlers, unset the memory
block's BlkAttr.FINALIZE (if the object is on GC heap), call the
object's destructor, destroy the monitor and zero the memory. I guess a
call to rt_finalize could be used as part of this procedure.
Or something like that.
