On Tue, 10 Aug 2010 16:03:42 -0400, Lutger <lutger.blijdest...@gmail.com>
wrote:
Steven Schveighoffer wrote:
On Tue, 10 Aug 2010 15:08:30 -0400, Lutger
<lutger.blijdest...@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
