From: bouncer@dev.null   
      
   Martin B. wrote:   
      
   > Personally I think it may well be possible and also good theory to   
   > separate these concerns and require "files" to always be "closed"   
   > explicitly prior to destruction. It just becomes impractical and   
   > additionally, people would then go and use a scope-guard like   
   > mechanism where the close/flush would be done explicitly in a   
   > destructor of the scope-guard object.   
      
   Which nicely illustrates why it is a bad idea to *require* that the   
   file is always explicitly closed before the destructor is called.   
   To prevent trouble when unwinding the stack because of some possibly   
   unrelated exception, users would have no other option then to somehow   
   invoke file::close() from the exception handling/stack unwinding   
   machinery.  The resulting error handling issues are the same as those   
   we face when the destructor just implicitly closes the file descriptor   
   if it is still open.   
      
   - Wil   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)