home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / eiffel / 1383 < prev    next >
Encoding:
Text File  |  1992-12-20  |  2.1 KB  |  45 lines
  1. Newsgroups: comp.lang.eiffel
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!spool.mu.edu!umn.edu!csus.edu!netcom.com!nagle
  3. From: nagle@netcom.com (John Nagle)
  4. Subject: Re: Semantics of invariants
  5. Message-ID: <1992Dec18.033811.9746@netcom.com>
  6. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  7. References: <1992Dec15.213603.16406@bony1.bony.com> <1992Dec16.163847.17559@nrao.edu>
  8. Date: Fri, 18 Dec 1992 03:38:11 GMT
  9. Lines: 34
  10.  
  11. cflatter@nrao.edu (Chris Flatters) writes:
  12. >If the values of class attributes are not modified outside of the procedures
  13. >and functions of that class it is sufficient to check the class invariant
  14. >on exit from each function or procedure since the invarient (sic) will not
  15. >change between exit from one function/procedure and entry into the next.
  16.  
  17.        This is not quite sufficient, unfortunately.  The usefulness of
  18. class invariants is that one can assume them to be true at entry to
  19. a procedure exported from a class.  Procedures in the class are coded
  20. assuming the invariant is true (and, strictly, shouldn't assume anything
  21. about the class variables that isn't expressed in the invariant).
  22. After manipulating the class variables, the procedure must make the
  23. invariant true before returning.  This is a good, sound way to program.
  24.  
  25.        There's a hole, though.  Class reentrancy is a problem.  If a
  26. procedure exported from a class can, directly or indirectly, call
  27. itself or some other exported procedure on the same object, the
  28. object can be entered with the invariant in an invalid state.
  29.  
  30.        This comes up in some C++ programs which use "iterators".
  31. If an iterator iterating over a list calls a function which, say,
  32. calls the function which
  33. deletes something from that list, the iterator may dereference a pointer
  34. to a deleted object.
  35.  
  36.        The implication is that if an object has functions which could
  37. potentially call something which reenters the object, the invariant must
  38. be rechecked at object entrance, as well as at exit.  
  39.  
  40.        Many invariant checks can be optimized out by a good compiler.
  41. How well are existing Eiffel compilers doing in this area?
  42.  
  43.                     John Nagle
  44.  
  45.