JAL wrote:
This is as expected in a garbage collected runtime, but you can still do
deterministic cleanup:
http://www.geocities.com/Jeff_Louie/oop26.htm
I don't want that. try/catch can't do
std::vector<boo st::shared_ptr< Resource> > items;
I need my destructor, not only for deterministic cleanup in a scope, but
also for deterministric cleanup in containers. If you store resources
that require destruction (non-memory-only resources) in a container, you
still want to make sure that when the container goes out, all its items
go out automatically. Maybe if you program in a fully managed
environment you don't use destructors that often, but I essentially wrap
unmanaged code to managed interfaces, and therefore all of my classes
requires Dispose() to release unmanaged memory in a timely manner. You
could say they'll eventually be garbage collected, but I'm saying it's
too late. Some resources are very critical and must be destroyed
deterministical ly, and unmanaged memory must be deallocated as soon as
possible too.
Just imagine storing high resolution color images wrapped in a very thin
managed class. I don't care if the garbage collector doesn't kick in for
a while for the 16-byte unmanaged part, but my 50 MB unmanaged data had
better be deallocated when they're not used anymore. I can't wait until
the garbage collector runs out of managed memory, because my unmanaged
memory will run out much earlier. My example shows that a single missed
call to Dispose can be just as catastrophic in the managed world as it
is in the unmanaged world, except the unmanaged world has tools
(boost::shared_ ptr) to deal with that situation. And I believe C++/CLI
is prepared to deal with those cases too. C# is not. Correct me if I'm
wrong.
You could say I'm just spoiled by modern C++ and boost, but C# is a step
behind from this point of view, and .NET itself is a step behind for not
supporting const correctness too. It's also a step forward for
properties, events, reflection and self-contained packaging (managed
assembly) support.
Tom
