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-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!newshub.sdsu.edu!logbridge.uoregon.edu!usenet01.sei.cmu.edu!news.sei.cmu.edu!not-for-mail From: John Hudak Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada) Date: Tue, 08 Mar 2005 09:51:29 -0500 Organization: Software Engineering Institute Message-ID: References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> NNTP-Posting-Host: pcyb.sei.cmu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: usenet02.sei.cmu.edu 1110293489 7091 128.237.11.63 (8 Mar 2005 14:51:29 GMT) X-Complaints-To: abuse@sei.cmu.edu NNTP-Posting-Date: Tue, 8 Mar 2005 14:51:29 +0000 (UTC) In-Reply-To: X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 Xref: g2news1.google.com comp.lang.ada:8858 comp.lang.c++:44603 comp.realtime:1063 comp.software-eng:4615 Date: 2005-03-08T09:51:29-05:00 List-Id: Peter Koch Larsen wrote: > "Ludovic Brenta" skrev i en meddelelse > news:87r7iu85lf.fsf@insalien.org... > >>Peter Koch Larsen writes: >> >>>Out of curiosiy, could you give some few examples where Ada catches >>>faults not found by a C++ compiler. I assume - of course - code >>>written in modern C++: no casts, functions instead of macroes, a >>>limited use of pointers and so on. >> >>Generally speaking, the very fact that you feel an urge to distinguish >>between "C++" and "modern C++" is an indication that C++ is a poor >>language containing many unsafe features, some of which you obligingly >>enumerated above. By contrast, there is no distinction between "Ada" >>and "modern Ada". Ada is safe by design, from the ground up. > > > We agree here. C++ is a "hackers language", in part because of its C roots. > > >>Now for one specific example, I wrote a buffer overflow in a C++ >>library a few years ago, and it took me and two other people 3 days to >>find it. The fix was, of course, trivial once the bug was found. As >>it turned out, this particular bug would have been impossible to write >>in Ada. I can't post the code, as it is proprietary and I don't have >>it at hand anyway, but the gist of it is that, in Ada, loop variables >>(a) are constants and (b) do not exist outside of the loop: >> >>procedure Proc (A : in String) is >>begin >> for J in A'Range loop >> J := J + 4; -- illegal, J is constant inside the loop >> end loop; >> Do_Womething_With (J); -- illegal, J no longer exists >>end Proc; > > > This is inherited from Pascal if I remember correctly. Of course, good C++ > style is to declare your variable in the loop. > >>Also notice that, in Ada, the "for" statement declares the loop >>variable automatically. >> >>The bug in the C++ library was that I was mistakenly reusing the loop >>variable after the loop, instead of the intended variable. Of course, >>the loop variable was an index pointing after the end of the buffer. >> >>Some other features that make Ada inherently safer than C++ are: >> >>* assignment is not an operator; it is an operation which does not >> return a value. Thus, bugs like "if (something = 0)" cannot exist. >> >>* case statements (Ada's equivalent of a switch in C++) are required >> to handle all possible cases. Thus it is impossible to forget one. >> And, of course, there is no "break;" crap in Ada. >> >>* conditions cannot mix "and" and "or" without parentheses. Thus >> there is no possibility that the programmer make wrong assumptions >> about precedence of operators or order of evaluation. > > > This seems ridiculous. I would expect a programmer to know the precedence > rules or at least insert parentheses if they are in doubt. > > >>* the type system, when used appropriately, makes it possible for the >> compiler to find semantic errors in addition to just syntax errors. >> For example, you can declare that Numers_Of_Apples and >> Numers_Of_Oranges cannot be mixed. This is not possible with C++'s >> typedef. > > > I like that idea. It is possible using templates, of course. Is it general > enough? If you replace "apples" with "weight" and "oranges" with "length", > is it then permissible to multiply a length with a weight but not add the > two together? > > >>* conversions from floating point to integer types involve rounding. >> The rounding is precisely and deterministically defined by the ISO >> standard for the Ada language. Similarly, floating-point and >> fixed-point types can be declared with known, deterministic, >> guaranteed precision. > > > This point sounds as if it restricts the environments where Ada can be used. > >>* pointer types cannot be converted to one another. You cannot >> convert a pointer-to-String to a pointer-to-random-object. > > > You can't do so in C++ either. (C has the conversion to/from void*). > > >>* accessibility rules are rather complex, but they are designed to >> minimise the chance of mistakes. Basically, the scope of a pointer >> type must be included in the scope of the pointed-to type. This >> makes many mistakes impossible, such as returning a pointer to an >> object which no longer exists. > > > I like that one to. > > >>* when the compiler cannot check some code statically, it inserts >> run-time checks which are guaranteed to catch all errors by raising >> exceptions. In C++ you must code these checks by hand, and of >> course at some point you'll forget one crucial check which will cost >> you days in debugging. > > > I sort of like this one as well - although raising an exception seems to be > to forgiving. > My conclusion is that there are some nice ideas out there, but that they > mainly protect against the "sloppy" programmer. Exactly - because not every programmer is well organized to keep all the nuances in their head, and observe them when coding. Furthermore, when components are integrated and one component talks to another is when the big debugging problems surface. One has to look at the history/motivation of Ada development versus that of C/C++...Ada certified compilers and tools strictly enforce the semantics of the language. It has been my experience that there is a lot of variability in C/C++ compilers in how through language semantics are adhered to. > > >>-- >>Ludovic Brenta. > > > Thanks for your answer > Peter > >