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



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.

--
Göran Andersson
_____
http://www.guffa.com
.



Relevant Pages

  • Re: Garbage collecting threads?
    ... An object without any references can be garbage collected. ... finalizer won't work because then the object is gone already. ... have to force all my users to do the same manual cleanup. ... already libraries that abstract such a scenario. ...
    (comp.lang.ruby)
  • Re: Garbage collecting threads?
    ... An object without any references can be garbage collected. ... finalizer won't work because then the object is gone already. ... Is it possible to have weak references in Ruby? ... philosophically -- if I wanted to do manual resource ...
    (comp.lang.ruby)
  • Re: Destructon of .NET objects
    ... > Why doesnt the runtime set the object to null when the finalizer has been ... Wouldnt this prevent a slew of bugs? ... If there are references to the object, ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Destructon of .NET objects
    ... > Why doesnt the runtime set the object to null when the finalizer has been ... Wouldnt this prevent a slew of bugs? ... If there are references to the object, ...
    (microsoft.public.dotnet.framework)
  • Re: Destructon of .NET objects
    ... > Why doesnt the runtime set the object to null when the finalizer has been ... Wouldnt this prevent a slew of bugs? ... If there are references to the object, ...
    (microsoft.public.dotnet.general)

Loading