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=3.8 required=5.0 tests=BAYES_00,FREEMAIL_FROM, INVALID_MSGID,RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,2c6139ce13be9980 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1014db,3d3f20d31be1c33a X-Google-Attributes: gid1014db,public From: "Ken Garlington" Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/10 Message-ID: <01bc8d8c$e608b740$6bb32399@default>#1/1 X-Deja-AN: 256068162 References: Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel,comp.lang.c,comp.lang.c++ Date: 1997-07-10T00:00:00+00:00 List-Id: > Eiffel implementations optimise a high percentage of dynamic calls to static > ones - 80-90%? Also, since the overhead of the calling mechanism is just part > of the cost of making the call (the total cost includes execution of the body), > the resultant penalty for default dynamic binding is reduced to 5-10% - > obviously not worth getting excited over, even for HRT systems. I dunno. I've seen more than one safety-critical embedded real-time systems that had to be re-worked at some cost to recover 5-10% overhead. > 2) Eiffel's contracts are stronger, more general, more flexible and more powerful > than in standard Ada. This doesn't mean Ada's contracting is useless by > any means. It's a tribute to the designers of Ada83 that support for > predefined contracts was included at the time it was designed. I'm > disappointed, of course, that they were omitted from Ada95. I'm not sure what was in Ada83 that was omitted in Ada95; however, I have noticed that Eiffel examples posted in various places tend to have assertions that are fairly simple in nature (range checks), etc that are directly representable in Ada. Those that aren't tend to be easy to do with good Ada design using exceptions (sort of the same "good design principles" that you discussed using in Eiffel to get the features made explicit in Ada). I think I'd like to see more cases where Eiffel is used in "hard" real-time safety-critical systems, and in particular some years of experience where Eiffel accurately detects - AND CORRECTS - for faults that are not routinely handled in equivalent Ada systems developed by the same vendor. I think that experience is already starting to emerge with respect to Ada vs. older languages in this domain, particularly for Ada's static checks. > > 3) Named parameter association is not necessary with systematic, sensible naming. > I confess to still using them in Ada (through force of habit) but usually > find that my formal and actual names are identical. Not our experience at all, particularly for commonly-used routines within a system. Named parameter association is extremely useful, in my experience. > Using named association > under such circumstances only serves to clutter the software text. Fortunately, in Ada, you can only use named notation where you want. > > > Don. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Don Harrison donh@syd.csa.com.au > > >