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.
Confusingly, if an object has a default constructor but is constructed from
anything else, clear will still call the default constructor.
I think that's reasonable. Otherwise the object would have to remember
in a hidden state variable which constructor it was initialized from.
I reckon it is
also surprising if you later insert a previously omitted default constructor
that the behavior can change a lot, especially when base classes are involved.
That's a consequence of the implementation bugs above, I think.
Andrei
