cline@cheetah.ece.clarkson.edu (Marshall Cline) (09/07/90)
In article <3354@stl.stc.co.uk> pgh@stl.stc.co.uk (P.G.Hamer) writes: >In article <404@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: >>Should we tend towards a situation where precondition checking >>will always be on, even in a released software product? >Which raises the even broader question. Can at least some preconditions be >expressed so that they can be checked at compile time? Doug Lea and I will be presenting a paper [1] at this year's SOOPPA (I'm told SOOPPA is pronounced like a Long-Islander says `super' :-) conference next week. Our work is exactly related to this question. We support a rather strong set of `class axioms' which can either be turned into runtime tests, some of which can hopefully be analyzed away by increased compile-time analysis. The syntax of our work is based on C++ (we call the system `A++' for `Annotated C++'), but the basic ideas could be applied to any strongly typed OOPL. C++'s support for signature-conformal subclassing (`public') and its separate support for non-sig-conformal subclassing (`private') helps, but is not essential. Another paper [2] which deals extensively with the present subject, will be presented at the `C++ at Work' conference later this month. The basic idea behind the scheme is to (conceptually) migrate precondition testing out to the caller. Thus a (I'll use C++ lingo) member function `f()' on object `o' with precondition `pre' will translate (conceptually) into: if (o.pre) o.f(); else throw exception; The advantage to this is that simple (ha ha ha!) flow analysis can eliminate some of these exception tests, without even the need for formal verification techniques. The problem is code bloat (there will in general be more than one call to a function, so placing the precondition test at the head of the function will mean less overall object code. The (first) solution to the code bloat problem is a wrapper function. Pretend we create an extra (hidden) member function `tested_f()' which tests the preconditions then calls `f()'. Then we still use a variant of flow analysis (or formal verification if the user wants it) to decide whether to call `o.f()' or `o.tested_f()'. If the compiler's output is assembly language rather than `C', a slightly more sophisticated solution is possible: alternate entry points: tested_f: ...do the precondition tests... f: ...do the regular function... ret The problem with both these situations, is that `foreign languages' won't know about this scheme, so their calls to `f()' will call the *UN*tested version. Soln: reverse the names: f: ...do the precondition tests... raw_f: ...do the regular function... ret Other than the `raw' entry point (and the jmp around `raw_f's stack setup after the precondition tests), this is *exactly* the same code generated by current C++ compilers. Thus A++ has the effect of allowing, on a CALL BY CALL BASIS, some function calls to `jump around' the called function's precondition tests. The more compile-time analysis, the more calls that can skip their precondition tests (we're not expecting that any piece of `real' software will ever be able to eliminate *all* its precondition tests -- we'd just like to eliminate the ones in low level loops, and we believe this would be a big step forward). The papers will be (please don't ask for preprints): [1] Marshall Cline and Doug Lea, The Behavior of C++ Classes, to appear in the Proceedings of the Symposium On Object-Oriented Programming Emphasizing Practical Applications, Marist College, 1990. [2] Marshall Cline and Doug Lea, Using Annotated C++, to appear in the Proceedings of the 1990 C++ At Work Conference, 1990. Marshall Cline -- ============================================================================== Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676 cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600 Career search in progress; ECE faculty; research oriented; will send vita. PS: If your company is interested in on-site C++/OOD training, drop me a line! ==============================================================================