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,6b6619eb9cada212 X-Google-Attributes: gid103376,public From: Chris Powell Subject: Re: Help me to chose between ADA 95 and C++ Date: 1999/12/14 Message-ID: <38566835.B4A2D48@rdel.co.uk> X-Deja-AN: 560619191 Content-Transfer-Encoding: 7bit References: <01bf37fb$a91afb60$0564a8c0@IS-D2D04C.test> <829rbv$a8m$1@nntp6.atl.mindspring.net> <01bf3e32$0b9dc880$022a6282@dieppe> <385112AE.7E2CFA9@rdel.co.uk> <833d8i$sjf$1@nntp5.atl.mindspring.net> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: postmaster@rdel.co.uk X-Trace: rdel.co.uk 945186889 24540 172.16.10.14 (14 Dec 1999 15:54:49 GMT) Organization: Blackbox Software UK Ltd Mime-Version: 1.0 NNTP-Posting-Date: 14 Dec 1999 15:54:49 GMT Newsgroups: comp.lang.ada Date: 1999-12-14T15:54:49+00:00 List-Id: Richard D Riehle wrote: > Since this is a response to something I said, I suppose I must say > something. > > 1) Type safety This is a real benefit of Ada that is not > as well represented in C++. The default in > Ada, for every construct, is type safe. The > default, in the C family of languages, including > C++, is type unsafe. It is true that one can > make C++ a little more type safe, but this requires > additional effort, an understanding of which > class to use (smart pointers, etc.) and a great > deal of careful programming. Even with that care, > a C++ maintenance programmer has all the tools to > easily violate the type safety another programmer has > diligently developed. Equal care is required in Ada, but possibly for different reasons. If types are defined incorrectly the resultant code ends up worse than if no types were used. Although explicit type conversions are required which should alert the programmer to a potential violation of the intended design, often there end up being so many conversions everywhere that the programmer no longer gives them a second thought. Good type design (especially in an OO system) would define types with appropriate functions acting on those types, possibly returning other types effectively defining allowed conversions. This is no different from defining C++ classes with appropriate methods which are effectively type safe through data hiding and a well defined public interface. > 2) Long-winded Speaking as a person reknowned for being a little > long-winded, at times, I do not find this to be a > bad thing. Seriously, Ada seems long-winded because > of the very rules that support the default for > type safety. Among these rules one finds a very > strict model for scope versus visibility, a language > feature that C++ has tried to adopt, but which falls > far short of that already integrated into the Ada > language. I can teach someone unfamiliar with Ada > to read it more easily than I can teach the same skill > to someone unfamiliar with C/C++. Some of Ada's long windedness is useful, but some adds no value and just obscures what the code is doing, e.g. the type conversions problem described above. > 3) Obscure Sure this falls into the category of what clinical > pyschologists call "projection." One of my favorite > columns from the magazine, "C++ Report," is at the > end of each issue and titled, "Obfuscated C++." One > create C++ code that is so mangled that even the most > expert of C++ practitioners is hard-pressed to explain > the exact outcome. It is far easier to write obfuscated > C++ that obfuscated Ada. Possibly, but if the aim is not to purposely produce obfuscated code, the class programming contructs of Ada 95 in their simplest form are more difficult to read than the simplest C++, e.g. Object'Class(This.all)'Access. (Note that I am waiting for responses to my 'nowhere leading' code example post and may have completely misunderstood Ada 95...) > 4) Error Prone Here we go with the projection again. The notion that > Ada is more error-prone than C++ reflects either an > ignorance of Ada, an ignorance of C++ or both. I can't > imagine anyone who knows both languages _well_ > making such a statement. I thought I did know both languages well, and I suppose I do not make many of the common mistakes in either language anymore: both languages were hard to learn. > No, C++ is not a swear word. C++ is a language with much to recommend > it for certain circumstances. However, anyone who would choose C++ > over Ada for safety-critical software, especially DoD weapon systems, > is suffering from a failure to understand the relative virtues of > both languages. One of my colleagues, who shall remain unnamed, says > that picking C++ over Ada is irresponsible. While I might consider his > opinion a little over-stated, he is not without some knowledge of this > issue. Did the coding standard for the safety-critical software developed allow full use of Ada 95 constructs? My experience of safety-critical software is that while Ada is usually the chosen language, most of the Ada language features are disallowed. I worked on one project where constrained types were not allowed (because they are more likely to raise exceptions than unconstrained types), no packages (because data hiding limited testability) and certainly nothing as difficult to test as inheritance/polymorphism could be used. > As to the STL, you are kidding, of course. The fundamental ideas of > STL are important and many of those components are excellent. I still > hear from colleagues here in Silicon Valley who grumble about their > reliability and the level of support offered by compiler publishers. > Add to that your parenthetical qualification, "(if used)," and you > have another interesting problem. Rarely do I seen anyone using > smart pointers or smart array classes as implemented in STL. This is > sad since these are among the more important STL components available. > Even when they are used, it is often so sparingly that one continues > to find pointer problems scattered merrily through the rest of the code. At least C++ has something in the way of a useful library that is part of the ANSI standard for the language. I always use STL containers now and it should ensure that my programs are free from the errors there would have been in my own implementations of containers and algorithms for sorting/seraching. The STL is also supremely more efficient than anything I would have time to write. In Ada I'd most probably use arrays and linear/binary searching and perhaps at a push I'd implement a linked list. An STL implementation is available for Ada (and all sorts of other useful libraries), but because it is not part of the standard, there seems to be a reluctance to use it. As for compiler publishers, the support we receive for our Ada environment is expensive and unhelpful. The Ada language requires a more complex compiler which has led to far more compiler bugs than C++, and we find more of them because the developer base for Ada is so much smaller than that of C++. And the compiler is so slow! Wow I've really gone off on one now! Sorry. The amazing thing is, I don't dislike Ada that much! I know that both languages have strengths and weaknesses and that computer languages are just tools. The languages are not so different compared to the people using them: some people write software that works, others never do. Chris.