Re: "Poll" Has C# Generally Replaced C++

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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<boost::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 deterministically, 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
.

Relevant Pages

  • Re: Destructor: not gauranteed to be called?
    ... If you make yourself familiar with the evolution of C++, you will find that, like most language features, it is a carefully weighed design decision and not a mistake at all. ... A destructor needs to to be public if and only if objects of the class in question are to be destroyed from outside member functions of the class itself and of its descendants, ... The only difference is that you will screw up at a higher level (class logic, rather than memory management). ... This> means that memory has a direct correlation to other resources, ...
    (microsoft.public.dotnet.languages.vc)
  • Re: correctly cleaning up and exiting the app.
    ... There is no correct clean up ... but then the destructor clears only 2 items. ... error when storing raw pointers in containers is to forget to delete those ... container destruction in this instance is a two stage operation: ...
    (alt.comp.lang.learn.c-cpp)
  • Re: GC destructor calls
    ... reference you claim to ... Contained object is through your Container object, ... > called BEFORE the Container destructor. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Dipose vs Destructor
    ... resources and native resources in a managed C++ class? ... C++/CLI implements the destructor and finalizer semantics in any ref class T ... These cleanup mechanisms are hidden from the C++/CLI ...
    (microsoft.public.dotnet.languages.vc)
  • Re: OLE - link or embed?
    ... We have a generic array container. ... If the array has a destructor for its contents, ... int removeprimes(ARRAY *a, void (*destructor)) ...
    (comp.lang.c)