Lutger wrote:
Andrei Alexandrescu 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.
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.
The confusing part (to me) comes from the special role of the default
constructor in the current scheme. You cannot use clear() to release a resource
constructed with it because it is immediately acquired again and hold onto until
(if at all) the collector decides to collect it. Not to mention it is acquired
twice. It seems to be unsuitable for acquiring an (expensive) resource and yet
that is exactly what tdpl illustrates.
The default constructor for classes already has a special role, e.g.
it's the only one known polymorphically and the only one used by the
built-in object factory.
If someone acquires a resource in the default constructor, one can
presume that all other constructors also allocate that resource so
ownership of the resource is part of the object's invariant.
Consequently, the destructor can assume ownership of the resource. If
clear() initializes the object by bitblitting the initial values over
the object's fields, then the later-invoked destructor will fail.
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
Thanks, that will help with the other points. Should I file bugs?
Yes please.
Andrei
