On Mon, 09 Aug 2010 15:46:27 -0400, Andrei Alexandrescu
<[email protected]> wrote:
Lutger wrote:
Steven Schveighoffer wrote:
On Mon, 09 Aug 2010 08:28:38 -0400, Andrej Mitrovic
<[email protected]> wrote:
It's rather perplexing, isn't it? It states in TDPL:
"After you invoke clear, the object is still alive and well, but its
destructor has been called and the object is now carrying its
default-constructed stated. During the next garbage collection, the
destructor is called again, because the garbage collector has no idea
in
what state you have left the object."
This seems totally wrong, what if an object has no default constructor?
The spec used to say (maybe it still does) that a destructor is
guaranteed
to only ever be called once.
The spec still does, it is not updated since it describes delete, not
clear. If you omit the default constructor, no constructor will be
called. Also not for the base classes even if they have a default
constructor. This looks like a bug.
Yes, not calling the constructors of base classes is an implementation
bug. If a class does not define any constructor at all, it has a de
facto default constructor. If a class does define some constructor but
not a parameterless one, it is a bug in the implementation if clear()
compiles.
How can this be decided at compile time?
basic counter-example:
class C
{
this(int x) {}
}
// how do you statically disable this?
void foo(Object o)
{
clear(o);
}
void foo(C c)
{
auto c = new C(1);
foo(c);
}
I always thought clear would simply overwrite the object with it's default
data as defined in the TypeInfo (i.e. before a constructor is normally
called). Calling the constructor is absolutely wrong. We don't want to
reset the object, we want to free it's resources. Re-constructing it may
reallocate resources *THAT WE JUST ASKED TO BE DESTROYED MANUALLY*. To
say clear as defined is a replacement for delete is complete fantasy.
-Steve
