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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f948976d12c7ee33 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-30 18:08:18 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: aek@vib.usr.pu.ru (Alexander Kopilovitch) Newsgroups: comp.lang.ada Subject: Re: Boeing and Dreamliner Date: 30 Jun 2003 18:08:18 -0700 Organization: http://groups.google.com/ Message-ID: References: <3EFC6FC2.B96DAEA4@adaworks.com> <1056731513.272294@master.nyc.kbcfp.com> <3EFF2F6D.3793971@adaworks.com> NNTP-Posting-Host: 62.152.82.160 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1057021698 22690 127.0.0.1 (1 Jul 2003 01:08:18 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 1 Jul 2003 01:08:18 GMT Xref: archiver1.google.com comp.lang.ada:39938 Date: 2003-07-01T01:08:18+00:00 List-Id: Hyman Rosen wrote: >Richard Riehle wrote: >> And those issues directly support the folly of even thinking about using >> C++ for this aircraft. > >Unsurprisingly, I disagree. You're talking about a situation where every >arithmetic operation in the code was carefully scrutinized. I'm sure that >in the cases were protection was left in the Ariane 4 code it did not >consist of allowing an Ada exception to be raised on overflow, but rather >coding in such a way that a correct numeric result would be produced. I >don't see why such scrutiny would not result in equally safe C++ code. There is vague but powerful thing - "expectations". In Ada world it is natural to expect that a component is suited and perhaps optimized for the particular purpose, unless otherwise it explicitly stated. The situation in C++ world is often quite opposite: it is common to expect that a class or class library provides some kind of acceptable/reasonable behaviour for some generic range of applications, and that behaviour must be overridden if/when we have have specific requirements. Therefore typical C++ programmer will not scrutinize the component unless he either has specific requirements or is alarmed by something - just because he *expects* from the component a resonable generic behaviour. And when he is given an Ada component, his habits - his usual expectations may well be in effect in the area where they are certainly invalid. Then to the habit of looking into source code as into a guide for documentation. It is also a habit of C++ world. Just one real example from Symbian OS C++ SDK (for SonyEricsson P800 smartphone): for preventing a dialog to be closed on application deactivation you should implement ShutL() method of CEikDialog class - this is said in the special separate page of SDK docs. But there is no ShutL() method in the documentation of the CEikDialog class, as well as in the documentation for its ancestors. Well, let's look into source code - CEikDialog class definition - and yes, we see there method ShutL() - it is private (so it was not included in documentation) but virtual (so it may be overriden). Thus C++ programmer often looks into source code, expecting to find there some clues for documentation. So, even the C++ habits may lead to disasters when applied in Ada world -- because expectations in these two worlds are quite different. And it is possible that exactly this thing was a contributing factor in Ariane 5 case. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia