At 09:42 10.10.2002 -0600, you wrote: >You never used <fstream> or CFile? Granted, the __finally blocks are a >nice addition, but they are a poor replacement for an object that cleans >itself up correctly and deterministically.
Objects rarely need to clean up after themselves in a deterministic fashion when there's a garbage collector. That's the whole point of a GC, after all. The exceptions are objects which hold unmanaged resources, on whose importance in the greater scheme of things we obviously disagree. >"_rare and exceptional_": Elaborate how the use of file handles, database >handles, OS handles, and COM objects is rare and exceptional??? I don't think I said the _use_ is rare and exceptional. The point of the discussion was cleaning up when an object is no longer needed, and _that_ happens only rarely, in terms of lines of code spent on it. My code usually has many more instructions for reading/interpreting and building/writing file contents than for opening or closing files... Same for other unmanged resources. Acquiring & releasing them isn't a terribly big part of the code, compared to "doing something" with them. So I don't mind having to type a few more lines to properly handle the acquisition & release. > All of these require deterministic finalization. It is just not > acceptable for robust code to release handles whenever the garbage > collector feels like it. If, when reading a file, an error occurs, the > user would expect that file to be closed. Are we going to go back to the > day when we ask the user to shutdown the application to make sure that > files get closed? What are you talking about? We have the IDisposable pattern to provide deterministic "finalization" (using quotes because this term has a different meaning in the .NET context). Nobody said that this should happen indeterministically. >This is just not true. Keeping the system in a well-defined state is more >than just releasing resources. It also includes whether or not objects are >half-constructed, whether operations are left half-done. Optimally, you >would like to have commit/rollback behavior in the face of exceptions. The >.NET garbage collector provides little support for this type of exception >safety. As long as constructors are properly written you won't have any "half-constructed" objects. Managed resources (= memory) left in undefined states are irrelevant since they will be cleaned up by the GC. As for unmanaged resources, it's the responsibility of the type designer to make sure that all acquired unmanaged resources will be released within the ctor before an exception is propagated to the caller. This could be done by calling a well-written Dispose method from within the ctor, for instance. Yes, it requires somewhat more effort than in C++ but it's not some kind of horrible defect -- especially since the GC is still there as an (indeterministic) safety net. Frankly, this whole thing seems more like a theoretical, not to say ideological, issue to me. There are billions of lines of working code written in languages such as C, Fortran, or older Visual Basic versions that also require manual cleanup, and need much more programming effort to make it work. Fully automatic commit/rollback behaviour in the face of exceptions is certainly on the wishlist for the ideal language but its absence is hardly a fatal flaw. >I disagree. I think the OP (original poster) reflects common concerns >regarding the garbage collector. These issues have also been talked to >death already in the DOTNET group. Search for garbage collector in the >DOTNET group. > >Consider also that Chris Sells is trying to get deterministic finalization >built in on top of the .NET model by adding reference counting. That would >be the best of both worlds. Interesting. Offering an optional deterministic finalization is certainly a good idea. I don't disagree on the desirability of such a feature, just on the importance of its current absence. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. Cheers, Chris
