Re: GC and dispose



Simon Hart wrote:
Agree. We often use the Dispose (IDisposable) for cleaning managed resources as well as unmanaged. We tend to use the Finalizer (Destructor) for unmanaged deallocation.

Could you explain why you prefer the finalizer instead of a manual call to Dispose for freeing unmanaged resources?

As far as I know you can never tell when the GC will finalize an object. So it might keep floating around forever as well. Which means that you could run out of handles for example.

Maybe I've misunderstood something behind GC and the finalizer?.

Max
.



Relevant Pages

  • 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: 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)
  • Re: Destructor: not gauranteed to be called?
    ... destructor and finalizer. ... It works as long as the language has stack semantics. ... I'm looking for a solution where I can guarantee deterministic ...
    (microsoft.public.dotnet.languages.vc)
  • Re: gc classes and destructors
    ... from another class the destructor is correctly ... > To make sure things are clear, this is actually the finalizer that isn't ... The destructor function that is emitted just supresses ... I've opened a bug with the CLR. ...
    (microsoft.public.dotnet.framework)

Loading