From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: ffc1e,a48e5b99425d742a X-Google-Attributes: gidffc1e,public X-Google-Thread: fac41,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public From: milkweed@plainfield.bypass.com (Anders Pytte) Subject: Re: Design by Contract in C++ (was Re: Papers on the Ariane-5 crash and Design by Contract) Date: 1997/03/24 Message-ID: #1/1 X-Deja-AN: 228015342 References: <332B5495.167EB0E7@eiffel.com> <332D113B.4A64@calfp.co.uk> <5gl1f5$a26$2@quasar.dimensional.com> <332E8D5D.400F@calfp.co.uk> <5gnttg$jkc$1@quasar.dimensional.com> <5gp3hd$i0l@mulga.cs.mu.OZ.AU> <5gqtve$1ol@gcsin3.geccs.gecm.com> <3336C971.5A7F@lmtas.lmco.com> Organization: Milkweed Software Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.lang.ada Date: 1997-03-24T00:00:00+00:00 List-Id: On Mon, Mar 24, 1997 4:15 AM, Paul Johnson wrote: >In article , >milkweed@plainfield.bypass.com says... > >>In a few hours my team developed much of the functionality of Eiffel's >>assertions (certainly the most essential functionality) for our C++ >>project by using macros. With minor changes, I could apply them to the >>problem suggested by Bertrand as follows. Show me how this will not work, >>please! > >How well do they handle redefinition and the inheritance of pre and post >conditions? Supposing I try to do any of the following: > >1: Weaken the precondition of a routine. >2: Strengthen the precondition of a routine. >3: Weaken the postcondition of a routine. >4: Strengthen the postcondition of a routine. >5: Weaken the invariant of a class. >6: Strengthen the invariant of a class. > >Eiffel allows me to do 1, 4 and 6. The others are prohibited by the >language. This is an important part of Eiffel, not just a nuance. Can >your C++ assertions do the same? > >Incidentally, how would it actually handle routine redefinition? Do I >have to copy all the assertions from the old version by hand? > You have some excellent points, although none of them are applicable to the Arriane case (regarding which I posted my note). And as I noted, we did not try to develop all the functionality of Eiffel's assertions - we were not even thinking of Eiffel at the time. I think the essence of your point is that the rules for assertion in Eiffel are designed to promote "design by constract", while my protean assertions place a heavier burden on the engineer. You are absolutely right! My point was simply that an engineer with a strong understanding of "design by constract" could, with care, easily implement much of the functionality of Eiffel's assertions. Having actually used most the techniques I describe, I can confidently say that they work better than an Eiffel engineer might expect! For example, regarding your final point. If when hiding behavior (i.e. override and not call the inherited behavior) then one needs to re-implement assertions. But often the contract has changed in this case. Otherwise, cut and copy is not that tedious! When modifying behavior (i.e. override and call the inherited behavior), one usually wants all of the original assertions in place. Items 1-6 could be easily accomplished by redefining assertions in the manner I described, in method overrides. But the language itself would not report 2, 3 or 5 as an error. The engineer obviously must know what s/he is doing! Another danger of the C++ macros which you overlooked regards multiple returns from a C++ function. One must take steps to ensure that ENSURE is actually called! Again, I am not claiming C++ is equal to Eiffel; I am merely objecting to claims that "design by contract" is an impracticle strategy using alternatives to Eiffel. Anders. -- Anders Pytte Milkweed Software RR 1, Box 227 Voice: (802) 472-5142 Cabot VT 05647 Internet: milkweed@plainfield.bypass.com -- Anders Pytte Milkweed Software RR 1, Box 227 Voice: (802) 472-5142 Cabot VT 05647 Internet: milkweed@plainfield.bypass.com