Re: Destructor: not gauranteed to be called?

It seems like the discussion has come to realize the difference between
finalizers and destructors. The first is non-deterministic and loosely
coupled, whereas the later is deterministic.

I do think there is a misunderstanding of the differences between
destructors in managed code and destructors in native code. While there are
differences, the discussion here hasn't highlighted any of them.

Arnaud Debaene wrote:
> I agree : the point is that there is NO destructors in .NET!!! There are
> finalizers, which are a different beast.CLI "destructors" have been
> mapped to finalizers as best as MS could (generating code that implement
> IDisposable, etc...), but this is by no way a native C++ destructor.

It's unfortunate that C# decided to use the tilda syntax for finalizers, and
even more unfortunate that the old Managed C++ syntax did the same thing.
However, the CLR makes no mention of destructors... so there's no real
mapping to do. Destructors are a language level implementation, not a
runtime issue.

> The whole point of the IDisposable interface is to circumvent this
> limitation of the GC, although it is still an inferior solution
> compared to the native, synchronous C++ destructor, IMHO.

I'm curious how IDisposable presents an inferior solution. From my
perspective as a language designer, I see IDisposable as the implementation
detail for destructors in C++. Really, you don't have to know anything about
IDisposable to use destructors in C++/CLI. To me, the biggest limitation
imposed on destructors as a result of IDisposable is that all destructors
are public and virtual. I actually that's a good thing, and it's a mistake
that unmanaged C++ allows destructors to be anything else.

> Agreed. There is NO destruction in .NET (nor in Java).

The premise of this statement is flawed. Destruction is a language level
service, because only the language can determine when it is appropriate to
deterministically cleanup objects. Why? Because the programmer needs to be
involved - otherwise you deal with the infamous halting problem. The CLR is
a collection of services that can be supplied to a running program. As long
as we're dealing with Turing Machines, the CLR will never be able to provide
deterministic cleanup as a service.

So, that means deterministic cleanup must be moved to the language level.
The best way to accomplish that and maintain a sense of cross-language
functionality was to create a common API. That was IDisposable. From there,
it's a matter of how the languages treat destruction semantics. C++/CLI does
everything that unmanaged C++ does, including automatic creation of
destructors when embedded types have destructors.

> No more memory leaks... The main reason for GC is to avoid raw memory
> leaks, not to get a better model for logical destruction of objects.

While GC is primarily about memory leaks, I would argue it serves to do much
more. C++ is inherently not type safe because it allows for things like use
of an object after delete. GC in the context of a language like C++ is the
only way to achieve type safety.

Also, if you are truly using Object Oriented Programming, objects will
represent resources like files, network connections, UI, etc. This means
that memory has a direct correlation to other resources, so GC has the
potential to cleanup a lot more than just memory.

Lastly, deterministic cleanup is really bad at cleaning up in certain
situations. A frequent example is shared resources that form a dependency
cycle. The impact of reference counting is well understood, and all of the
practices applied to unmanaged C++ frequently result in fragile programs. In
situations like these, garbage collection is the best solution. The problem
that usually results is programmers don't adapt to a different environment,
and instead try to contort deterministic practices to a non-deterministic
environment.

The short story... writing robust code still requires smart people thinking
solutions all the way through.

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
Bugs? Suggestions? Feedback? http://msdn.microsoft.com/productfeedback/


.

Relevant Pages

  • Re: Destructor: not gauranteed to be called?
    ... > implementation detail for destructors in C++. ... Destruction is a language ... Resource automatic freeing (mainly memory), ... The problem is that most developper know about finalizers (which ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Can I have back my destructors, please?
    ... memory, file handles, etc. ... make the consumer code uncompilable after such change?). ... IDisposable, Finalizers, Destructors, and the Garbage Man ... The article shows how to implement IDisposable and Destructor (Finalizers) ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Garbage Collection in C
    ... #> Garbage collection + finalisation allows you everything destructors ... so this garbage collection doesn't use any more memory than hand ... This involves a technical point of language design. ...
    (comp.lang.c)
  • Re: C++ has Boost libraries, C?
    ... But there are no classes, no inheritance, no complications. ... constructors, destructors, whatever. ... so you advocate extending the language with something that ...
    (comp.lang.c)
  • Re: Operator overloading in C
    ... I do not see why destructors are necessary. ... int fn ... qfloat *operator+; ... They have done C++ a huge favor in saving that language form the horrors ...
    (comp.std.c)