Re: Problem with C# not calling MC++ destrcutor

I guess you are technically correct about managed objects not having a
destructor, but they do support "~MyClass". In .NET-land should I be
referring to that as a Finalizer instead of a destructor?
As far as cleaning up resources, is it acceptable to put my clean up
code in "~MyClass" but also make use of manually calling
myClass.Dispose()? There are cases where I know that I don't need
certain objects anymore and it would be nice if I could put my cleanup
code in one place and know that it would be called regardless of what
caused the object to be destroyed.

I'm pretty surprised to hear that it is possible for my Finalizers to
not be called at shutdown. If I am being required to manually free up my
resources, what is the point of GC?

Thanks,
--Jeremy

Göran Andersson wrote:
Jeremy Chaney wrote:
I have an application written in C# that uses objects written in a
managed C++ DLL. When I exit my app, my C# classes have their
destructors called, but the MC++ objects that those classes hold
references to do not get invoked (I can observe this from both
breakpoints in the code, and trace output to the console).

I was under the impression that when my C# object goes out of scope, it
would automatically dispose of all of the references it is holding. I'm
new to GC, so maybe it doesn't work this way? I know that during
application execution objects with a ref count of 0 might not be cleaned
up right away, but when my process exits, shouldn't I be able to rely on
all of my objects being garbage collected?

Thanks,
--Jeremy

Managed classes doesn't have destructors, as there are no reference
counters at all, so nothing happens when the last reference goes away.
They may have Finalizers, that is instead called when the objects are
going to be garbage collected. You should avoid having a Finalizer on a
class if you don't need one, as having a Finalizer means that the object
has to go through at least two garbage collection cycles before it's
released.

If you need to release unmanaged resources in your classes, you should
implement the IDisposable interface (which includes have a Finalizer as
backup). If you only have managed resources in your classes, there is
nothing that you need to release, and so you don't need any Finalizer.

When the application ends, it will try to call the Finalizer of all
objects that has one, but if this takes too much time, it will just kill
the objects anyway. This is another reason to avoid having a Finalizer
if you don't need one, so that the finalizing queue only contains
objects that really needs to be finalized.

.

Relevant Pages

  • Re: Dipose vs Destructor
    ... resources and native resources in a managed C++ class? ... C++/CLI implements the destructor and finalizer semantics in any ref class T ... These cleanup mechanisms are hidden from the C++/CLI ...
    (microsoft.public.dotnet.languages.vc)
  • RE: Pointers?
    ... There are finalizers which are expressed using C++'s destructor syntax. ... object, if it implements a finalizer, it is put on the finalization queue and run at an undetermined time in the future by the GC's finalization thread. ... >Dispose to free resource on demand. ... >safe in case Dispose wasn't called by the programmer. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Destructor: not gauranteed to be called?
    ... So was this response inaccurate: ... "For managed object on the GC heap, the Finalizer MAY be called if you don't ... This implies you can't count on either the destructor OR the finalizer from ... If I create a ref class, ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Problem with C# not calling MC++ destrcutor
    ... referring to that as a Finalizer instead of a destructor? ... In the proposed implementation of the IDisposable interface, the finalizer is calling ... You should always try to call Dispose if you can, as that is a more efficient way of freing up the resources. ... You should always try to free up all unmanaged resources as soon as possible. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Interop question: .NET COM object created in C++ doesnt seem to get destroyed
    ... If you use destructor syntax, ... actually create a finalizer. ... If you need deterministic cleanup of a .NET object, ... The CLR, the default ...
    (microsoft.public.dotnet.framework)