Re: recommended way to create vc windows application by Tamas
Tamas
Wed Apr 26 13:42:09 CDT 2006
Arnaud Debaene wrote:
> The whole problem with .NET GC is that it doesn't manage all kind of
> resources, only memory. All other resources (eg, files, kernel objects,
> sockets, database connections....) must be managed manually, and the support
> in .NET for easing this management (IDisposable) is far inferior IMHO to the
> C++ alternative (the RAII idiom).
I completely agree. It solves 50% of the problems automatically, but
makes the other 50% even more painful than it was in native code. It's
almost unimaginable that recently designed modern systems no longer care
about proper resource management. Make no mistake, I'm not against
garbage collection, I just can't comprehend why solving some memory
management issues in an elegant way has to automatically lead to the
complete elimination of such a safe and successful concept as
deterministic destruction. It is clear that for resources and for
unmanaged memory management it is still preferred to use reference
counted smart pointers. Only that can't be implemented under .NET in a
portable way, because value types that use stack syntax don't support
copy constructors, and reference types that can have copy constructors
don't support deterministic destruction.
> There is now a good alternative with C++/CLI and it's stack semantic, but I
> fear it will stay away from "mainstream" .NET developpement wich is done in
> C# or VB.
C# has the using keyword, which is not as elegant as the C++/CLI stack
syntax, but it does the same job. The situation is bad in VB, though.
A big problem is that it's often very hard to guess from the name of the
class whether it requires a call to Dispose or not. You have to remember
whether the class is IDisposable, or simply a memory object.
Unfortunately a class' role may change during the development, and
something that used to be a pure-memory object may one day include a
resource. If nothing else, a native object, which automatically makes it
an IDisposable, but there is already 1000s of existing lines using the
object with the assumption that a simple garbage collection is enough.
How many times it happens in C++ that we make a simple class without a
destructor, but later as the project grows, a destructor will eventually
be added?
Another aspect is that not every resource is an "auto" variable inside a
function. There are cases when a resource needs to be passed into and
out of functions, and yet we need deterministic destruction. For those
cases C++ offers boost::shared_ptr, a reference counted smart pointer. I
would like to see a .NET way of doing that, preferably an implementation
that's a first class citizen in all languages, and can be passed from
one DLL to another.
It's not entirely out of place to store resources in containers,
especially if an object is a wrapper around an unmanaged class. One
could argue that real resources are not typically stored in containers,
but wrapping a native C++ class by definition makes the ref class
IDisposable, and thus a resource that requires much more than simple
garbage collection. Again, a reference counted smart pointer would do
wonders. How nice it would be if I could wrap unmanaged code into ref
classes using C++/CLI, and be able to pass it to C# and VB programmers,
without having to worry about resource management?
Yes, there is a concept called finalizer, but it's only called when the
system runs out of managed memory. The system may run out of native
memory much before the .NET framework realizes that a garbage collection
would be required, so the finalizer is an inferior solution compared to
a reference counted smart pointer for wrapped native objects.
To be completely fair, the problem of storing IDisposable objects in
.NET collections can be solved by writing special containers that take
care of calling delete/Dispose for each item. So I'm not saying that
resource management problems are impossible to solve in .NET. However, I
still reserve my statement that it's significantly more painful than in
modern ISO C++, and that the .NET framework doesn't provide any help
with that in its current state.
Tom