TDPL: Manual invocation of destructor

[Jacob Carlborg]

On 2010-08-09 22:57, Andrei Alexandrescu wrote:
> Lutger wrote:
>> Andrei Alexandrescu wrote:
>>
>>> Lutger wrote:
>>>> Steven Schveighoffer wrote:
>>>>
>>>>> On Mon, 09 Aug 2010 08:28:38 -0400, Andrej Mitrovic
>>>>> <andrej.mitrovich at gmail.com> 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.

Why doesn't the object factory look something like this ?
factory(ARGS...)(string classname, ARGS args);

> 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


-- 
/Jacob Carlborg