Re: Destructor: not gauranteed to be called?
- From: Tamas Demjen <tdemjen@xxxxxxxxx>
- Date: Wed, 01 Feb 2006 11:07:44 -0800
Gerhard Menzl wrote:
Have you ever encountered an example of a network or file resource cycle? For the special cases where cycles do occur, there are well-tested techniques that can deal with them, such as shared_ptr/weak_ptr. In most resource scenarios, exclusive ownership suffices, and you don't even need reference counting.
I completely agree with that. The .NET framework aims to solve the memory leak problem, and it probably does a good job at that. However, it doesn't provide the tools needed to solve the deterministic resource destruction problem, with the exception of C++/CLI. Even that's lacking good library features, such as shared_ptr/weak_ptr, but they can be solved by 3rd party vendors.
In C++ we routinely use constructs like vector<Resource>, and when the
container goes out of scope, it guarantees that all owned resources are
properly destructed. In a .NET List<Resource^> it is not happening. The
stack syntax doesn't extend to containers, and there seems to be no
..NET library to implement some kind of a reference counted smart pointer. And there's no .NET collection that "owns" the resources that it holds either. Those who routinely wrap unmanaged C++ code in C++/CLI feel unsafe, especially when the wrapped assemblies are going to be used in C# or VB.
Why do I care about this when the .NET framework has finalizers? Because my unmanaged code uses far more memory than the managed part. There is not enough garbage in the managed memory for the GC to kick in, at least not before I run out of native memory. If I have to depend on the finalizer to destroy my unmanaged objects, sooner than later the native heap will be full.
Some will disagree with me, but this is how I view this issue, and
it concerns me. The .NET framework supports and uses exceptions
extensively, and C++ programmers know how dangerous it is to use exceptions without proper support for deterministic destructors. It's like walking on a minefield. I realize that C# has the "using" keyword, which is the first step toward safe resource destruction, but it only works for local objects, not for resources stored in a container. When it comes to objects stored in collections, the .NET framework doesn't provide a tool better than a vector<Resource*> in native C++. ISO C++ can be error prone, but at least it has the tools to be safe.
The worst thing is that many C# and VB programmers are not used to dealing with destructors, because they live in a false sense of security
that the GC handles everything automatically, and when this attitude is
mixed with exceptions, it could cause a disaster. Mutexes will not be unlocked. Files will not be closed. Native memory will not be reclaimed, because of the lack of destructors that are guaranteed to be called.
Tom .
- Follow-Ups:
- References:
- Re: Destructor: not gauranteed to be called?
- From: Gerhard Menzl
- Re: Destructor: not gauranteed to be called?
- Prev by Date: Re: Destructor: not gauranteed to be called?
- Next by Date: Re: Destructor: not gauranteed to be called?
- Previous by thread: Re: Destructor: not gauranteed to be called?
- Next by thread: Re: Destructor: not gauranteed to be called?
- Index(es):
Relevant Pages
|
