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



The need for this destructor (I'm going to call it that until someone
tells me what to call it in C#) is surprising to me.
Actually, there's no need for it in the form you have posted. See below how
to implement it "correctly".

Shouldn't they have their destructors called when "~MyCSharpClass" is
called?
No, finalizers (or call them destructors) don't call finalizers on instance
members automatically (I don't know if and under which circumstances they do
in C++, but I guess you think they do in C#). As Göran has stated in the
reply below, objects that have finalizers are placed in the finalization
queue and GC calls their finalizers on its finalizing thread when it finds
appropriate.

While Göran has explained the "theory" of what you should do, please let me
sum up how to implement what you have in practice.
Your finalizer code (the code you've posted) should go to the Dispose(bool
disposing) method you'll add to your class. You will also implement
IDisposable interface and from its Dispose() method, you'll call
Dispose(true) and also call GC.SuppressFinalize(this); - which will prevent
the object to be placed in the finalization queue => the finalizer will not
be called when the object is collected. Your finalizer would call the
Dispose(bool) method and you have done so already, that's why you are
calling SuppressFinalize().

Your finalizer should call Dispose(false) which will get rid of all
references to its instance members (set them to null) and rely on let their
finalizers to be called in the next collection (in case they have any and
they have not been Disposed yet). You should not rely on the finalizer to be
called - it's there just for the case you "forget" to call
IDisposable.Dispose() method on your object.

The whole point you are missing, I think, is that IDisposable.Dispose() is
meant to be called deterministically by you when you know you need to clean
up the resources used by the object.

"Jeremy Chaney" <j*c@xxxxxxxxxxxxxx> wrote in message
news:e$T0EnvRHHA.4188@xxxxxxxxxxxxxxxxxxxxxxx
Lebesgue wrote:
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?

GC is here to clean up unreferenced _memory_. You should deal with other
(unmanaged) resources using the dispose pattern in C#. There has been a
long
thread recently (named C++/CLI is the way to go) where a reference
counted
model for disposing unused resources in C# has been proposed.

Can you show us your finalizers? My guess is you are trying to use them
the
way they were not meant to be.



I think I'm sinking in over my head here... :) When you say Finalizers,
do you mean my "~MyClass" method?

Here it is:

~MyCSharpClass()
{
foreach (KeyValuePair<Char, MyManagedCPPClass> kvp in m_MyMap)
{
kvp.Value.Dispose();
}
m_myotherManagedCPPClass.Dispose();
}


The need for this destructor (I'm going to call it that until someone
tells me what to call it in C#) is surprising to me. The objects that I
have to call Dispose on are both Managed C++ objects. Shouldn't they
have their destructors called when "~MyCSharpClass" is called? . Before
I added the calls to Dispose, "~MyCSharpClass" was always called, but
the destructors for my Managed C++ objects were not. (I fixed this with
the addition of Dispose).

Thanks,
--Jeremy


.



Relevant Pages

  • Re: basic question...destructors confusion
    ... I *always* implement IDisposable even if I am not using unmanaged resources ... Dispose() instead of using finalizers. ... Protected Overrides Sub Finalize() ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Clean Up managed resources
    ... //Clean up unmanaged resources ... If somebody called Dispose on your object, ... then they have their own finalizers which will be run automatically ... The garbage collector will tell each managed class to ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Problem with C# not calling MC++ destrcutor
    ... You should deal with other resources using the dispose pattern in C#. ... At the next garbage collection they will be placed in the queue of object to be finalized, and a background process will call their finalizers eventually. ... If you implement IDisposable, it will make the memory management much more efficient. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: garbage collection of open resources
    ... > It does, there's just no guarantee. ... If finalizers take too long or create ... not calling Dispose() on a disposable object is a bug in the ... I just wanted to point out that resource leakage ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Filestreams
    ... I wouldn't trust this approach; firstly, objects *never" dispose ... finalizers aren't fully guaranteed to run at ... on the Log class. ...
    (microsoft.public.dotnet.languages.csharp)