Re: Destructor: not gauranteed to be called?

Peter Oliphant wrote:

> Personally, I think it is against the whole
> concept of a destructor.
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.

>
> Let me make this clear. I have always realized that when GC wasn't in
> play that if I created something (then via 'new') I had to destruct
> it manually to avoid memory leaks. That is, it was never gauranteed
> the destructor would be called unless I invoked it via a delete call.
> But, with the introduction of GC, anything created as a gc object
> shouldn't need to be destructed manually, as the application is
> suppose to keep track of whether something is being used anymore by
> anyone before GC destroys it.
The GC is asynchronous, and your never sure it will execute a finalizer for
a given object.(not the destructor mind you, since it doesn't exist, the
finalizer!).
The other point is that, since you don't know in which order finalizers are
run, you can't reference any external object from within a finalizer, so
you're really very limited in what you can do within them.

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.

> What I see emerging is this. GC was created to help with the concept
> that destruction of an object is tough to do when who 'owns' it is
> unclear, or when it is unclear whether everyone's done with it. This
> caused memory leaks in the case that 'nobody' took final
> responsibility (or couldn't based on the info available). But the
> solution to this is now generating another issue. Lack of reliable
> destruction!
Agreed. There is NO destruction in .NET (nor in Java).

> Destruction is now not gauranteed at any time you don't
> specifically delete it. BUT WAIT! The whole point of GC was to AVOID
> having to know when to do delete. So, if we are forced to do delete
> to insure the destructor get run, then what did we gain from
> introducing GC?
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.

> That is, if we now still have to delete at the right
> time, this implies we know the instance is free to be destroyed.
More precisely, we have to *Dispose* the object at the right time...

> Thus, we lose the advantage we got. Or more precisely, we have add
> complication that introduces more possible pitfalls, and we are STILL
> required to tell the application when to destroy something if we want
> our destructors have any reliable meaning!

Yep. I do not believe anyway the computer will ever be able to *guess* what
the programmer wants, so there will ever be a manual indication of when an
action must be done (including destruction/finalization/release of
ressource).

> And, again possibly showing my ignorance, when did finalizers come
> into play? Is this part of the C++ standard?
No, they are part of the .NET standard. They are a very central feature of
..NET, and you should document yourself to get a firm grasp on the subtle
differences between destructors and finalizers.

To make the story short, a finalizer is an optional member function that is
possibly called (if it exists!) by the GC some time before the GC reclaims
the object memory and after the last reference on the object has been
released. You've got no guarantee at all on the order on which finalizers
for different objects execute.

> Basically, I think things have gotten so complicated in this
> destructor area that we have just traded one set of problems for
> another.
Possible. Another explanation is perhaps you didn't master the differences
between finalizers and destructors, and you expected something of the system
without taking care of checking in the documentation wether your
expectations were justified.

Arnaud
MVP - VC

PS : IMHO, the Java, C# and Managed C++ choice of using the C++ destructor
syntax (~ClassName) to express the finalizer is a bad mistake that led many
developpers into misconceptions of that kind.


.

Relevant Pages

  • Re: Destructor is not called
    ... ..NET doesn't use destructors, it uses Finalizers. ... have in the class's Dispose() method and simply call Dispose when your code ... that has a destructor. ... ChannelComm is not called. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Removing Delegates in Dispose method
    ... but destructors (or finalizers) are invoked automatically ... and can't be invoked explicitly by the garbage collector. ... which has no C++/CLI) a finalizer, not a destructor. ... I tried overriding the form's Dispose method, ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Why not destructor?
    ... Great post Ian, ... I would just want to add that if you really need a destructor you should ... the finalizer off for our object when we know that the dispose method ... .NET tries to run all finalizers (C# ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: Objects dont get Garbage Collected
    ... if you supply a destructor you cannot predict when it ... A Form owns a Controller, a controller owns an Entity ... "GCed" to the console. ... finalizers of the entities) but this doesn't happen. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Destructors in C#????
    ... a destructor is automatically called by the garbage ... Sub Finalize method which is the same as a C# destructor. ... implementation of Dispose to release resources. ... I thought finalize method gets called by GC right before it destroys ...
    (microsoft.public.dotnet.languages.csharp)
Loading