From: mordor.nospam@fly.srk.fer.hr   
      
   On 2012-06-06, Dave Abrahams  wrote:   
   >>   
   >> The real question is: should destructors be used to enofrce   
   >> invariants?   
   >   
   > Example, please.  Do you have in mind an invariant like, "every file   
   > used by the program is either closed or associated with some live   
   > object of type File?"   
   >   
   Yes.   
      
   >   
   > It's only an invariant if it is truly invariant.  If you can't   
   > guarantee that close() will succeed then you'd better not state an   
   > invariant like the one above, because it's a promise you can't keep.   
   > When designing contracts, brutal honesty is a hard requirement.   
   >   
   OK, I think I get it.   
      
   >> If yes, how do you report inability to fulfill invariants?   
   >   
   > You don't.  If your invariants are broken your program is broken and   
   > can't do *anything* reliably, because the whole program has been   
   >   
   Let's say I implement a class implementing high-precision floating   
   point arithmetic and also a square-root function Sqrt which promises   
   to return a properly rounded result of the same precision as the   
   input.  Now I call Sqrt(-1): what should happen?  The function can't   
   keep its promise since result isn't representable, so should I   
   1) throw an exception, or 2) terminate the program?   
      
      
   --   
         [ 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)