TDPL: Manual invocation of destructor

[awishformore]

On 09/08/2010 22:31, Andrei Alexandrescu wrote:
> Steven Schveighoffer wrote:
>> On Mon, 09 Aug 2010 15:46:27 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> 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.
>>
>> 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);
>> }
>
> Sorry, I got things mixed.
>
>> 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.
>
> Well this is my view as well and the original intent of clear(). The
> problem is, if someone defined a default constructor, they presumably
> have a nontrivial invariant to satisfy. I'm unclear on what's the best
> path to take.
>
> Andrei

Quite frankly, I can't imagine any situation where I would ever want to 
use the clear the way you currently intend to implement it, and if 
you're unclear, you will probably agree that you don't really see a good 
way to implement it as things stand.

Rather than removing delete and implementing a completely useless clear, 
I would like to see an improved version of the GC that can correctly 
handle delete. Maybe you are approaching the issue from the wrong 
perspective.

/Max