0326a20b   
   From: brangdon@cix.compulink.co.uk   
      
   edward.rosten@gmail.com (Edward Rosten) wrote (abridged):   
   > I don't see that as an alternative, unless I've misunderstood. If   
   > you don't put close() in the destructor, you rely on the caller of   
   > the class both remembering to destroy it properly   
      
   Your class's destructor can check whether close() was called, and   
   assert if it wasn't. So the caller's mistake will be detected the   
   first time the code is executed. This ought to be enough in practice,   
   if they have a testing regime.   
      
   (If you believe in defensive programming, you can include some of that   
   in the destructor too: close the file, log the error, whatever.)   
      
   > and checking for errors when it has done so.   
      
   You can expose close() through a member function that throws on error,   
   if that's appropriate.   
      
   -- Dave Harris, Nottingham, UK.   
      
      
   --   
         [ 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)