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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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:11:42 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newshub.sdsu.edu!elnk-pas-nf2!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: Richard Riehle Newsgroups: comp.lang.ada Subject: Re: Boeing and Dreamliner Date: Mon, 30 Jun 2003 18:14:42 -0700 Organization: AdaWorks Software Engineering Message-ID: <3F00E081.898E3C4A@adaworks.com> References: <3EFC6FC2.B96DAEA4@adaworks.com> <1056731513.272294@master.nyc.kbcfp.com> <3EFF2F6D.3793971@adaworks.com> Reply-To: richard@adaworks.com NNTP-Posting-Host: 41.b2.41.e1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 1 Jul 2003 01:13:20 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:39939 Date: 2003-07-01T01:13:20+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. C++ is simply not designed this way. Ada is. In C++ it is perfectly legal to do all kinds of assignment statements where the result is not entirely predictable. A key difference between Ada and many other languages is the absence of structural equivalence in favor of named equivalence. That is, the fact that there might be some possible structural compatibility between objects with different names (or type designations) is never sufficient justification for a legal operation involving types of different names. Even unchecked operations, when there is a potential for an erroneous result, result in a warning in better Ada compilers. Also, unchecked assignment (Unchecked_Conversion) only permits assignment in the direction for which it is instantiated. This eliminates many kinds of errors. Quite simply, the amount of error checking performed by an Ada compiler is substantially greater than in C++. This does not mean C++ is evil. It simply means it is inappropriate for software that demands a high level of dependability, especially when one has Ada available as an option. I really don't want this to sound like C++ bashing. However, the more I learn about C++, the more I realize it is an excellent language for certain classes of problems, but is more dangerous for safety-critical software than Ada. By all means, use C++ for graphics, statistical analysis, business problems, and similar kinds of problems. But, do not use it for software where life and safety are involved. This is simply a matter of selecting the right tool for the right job. > > I am also confident that, pressures from resume-builders > > notwithstanding, they will realize the value of using contemporary Ada, > > with its excellent record for software safety, instead of a language so > > characterized by unpredictability that they could never be sure that some > > undetected behavior might manifest itself long after even the best of > > testing has been completed. > > I obviously disagree with you about the suitability of C++, but I > certainly agree that Ada is a fine choice as well. As for resume > building, I would just let such people do their building elsewhere. I know you are a skilled and experienced C++ developer. Does it not occur to you that simple little things such as automatic type promotion, incorrect placement of curly braces, and errors in pointer arithmetic, to name a few issues, might result in questionable code? What about incorrectly defined destructors? Or default assignment operations? Or many more such entertaining features of C++ that add power, but also add the potential for undetected errors? You know the list is even longer than the one I just presented. Richard Riehle