On 07/14/2010 02:38 PM, Max Samukha wrote:
On 07/14/2010 12:50 AM, Andrei Alexandrescu wrote:
On 07/13/2010 03:51 PM, Trass3r wrote:
Does it really add so much complexity to the compiler that it's worth
removing?
It adds misconception and confusion. delete must disappear from D.
Andrei
FWIW, the current implementation of clear() has at least one problem
that guarantees my not using it: the default constructor may be
arbitrarily complex (for example, it may allocate an expensive
resource), so running it on the dead object is not acceptable.
You mean class objects, right? I agree. I think it's okay to fill the
object with its stateless .init members, which would assuage the issue.
Also, as other people mentioned, resurrecting the dead object prevents
the program from failing early in case a dangling pointer to that object
gets dereferenced.
There is no early failure with dangling pointers.
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.
This way the objects the dead object may reference can be GCed
even in the presence of dangling pointers the dead object. Additionally,
the probability of the program failing early on a dangling pointer
dereference is high because the vtable pointer is null (any virtual call
is bound to fail).
Or something like that.
I think the vtable could remain valid.
Andrei
