Should destructors be able to tell who called them?

[Steven Schveighoffer]

On Tue, 10 Aug 2010 16:03:42 -0400, Lutger <lutger.blijdestijn at gmail.com>  
wrote:

> Steven Schveighoffer wrote:
>
>> On Tue, 10 Aug 2010 15:08:30 -0400, Lutger  
>> <lutger.blijdestijn at gmail.com>
>> wrote:
>>
>>> Steven Schveighoffer wrote:
>>> ...
>>>> This would make destructors a lot more useful.  Thoughts?
>>>>
>>>> -Steve
>>>
>>> My first thought was that they are actually two separate functions
>>> distinguished
>>> by a boolean, then Michel also mentioned the SafeD argument.
>>>
>>> atm I think it is better to let go of the destructor entirely for
>>> anything else
>>> than the GC collecting non-gc owned data as we now have. (the unsafe
>>> version,
>>> not compilable in SafeD). Rather provide a standard interface to
>>> implement and
>>> base deterministic release of resources on that. A much more simple
>>> version of
>>> IDisposable. clear() can call this one and leave ~this alone.
>>
>> Hm... something I just thought of that makes this bad, destructors are
>> special in that they automatically call base destructors.  You can't do
>> that with a simple function.
>>
>> But it could be done the way you say (with the caveat that you have to
>> manually call the base method).  I think clear should call ~this() in
>> addition to the dispose method because you don't want to have to  
>> duplicate
>> code.
>>
>> -Steve
>
> clear could check if the base classes implement the interface and act on  
> that.
> It already does the same for destructors.

Checking if a class implements an interface is not as trivial as accessing  
a member of the classinfo.  It's a linear search through the interfaces.   
Plus, I don't know quite how it would work, I'm not sure its doable.

BTW, I assumed that the most derived destructor simply called the base  
destructor implicitly, I didn't realize this was handled via the runtime,  
that seems like a low-hanging fruit opportunity for performance  
improvement...

-Steve