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,971aa11c293c3db1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-20 11:09:01 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!news.tele.dk!193.251.151.101!opentransit.net!wanadoo.fr!not-for-mail From: "Bertrand Augereau" Newsgroups: comp.lang.ada Subject: Re: Ada The Best Language? Date: Fri, 20 Jul 2001 20:14:14 +0200 Organization: Wanadoo, l'internet avec France Telecom Message-ID: <9j9s3t$kn8$1@wanadoo.fr> References: <5be89e2f.0107170838.c71ad61@posting.google.com> <5be89e2f.0107180235.726d46a8@posting.google.com> <9j3rrd$g71$1@s1.read.news.oleane.net> <5be89e2f.0107181300.4b4e93d7@posting.google.com> <3B57195E.A3A3FED@home.com> <9j93u6$1ua8$1@norfair.nerim.net> <3B586A17.862BA84D@home.com> NNTP-Posting-Host: afontenayssb-103-1-3-242.abo.wanadoo.fr X-Trace: wanadoo.fr 995652541 21224 217.128.201.242 (20 Jul 2001 18:09:01 GMT) X-Complaints-To: abuse@wanadoo.fr NNTP-Posting-Date: 20 Jul 2001 18:09:01 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Xref: archiver1.google.com comp.lang.ada:10365 Date: 2001-07-20T18:09:01+00:00 List-Id: > The best features of C++ still leave numerous faults in the final product: > > - No overflow checks > - In some cases, no divide by zero checks (this feature may need to be > enabled on your platform). "You don't have to pay for what you don't use" is the principle. > - No array bounds checking, unless you use classes to do this for you > (a very costly approach for small arrays) Plain wrong. Just look at STL's vector. You can use it with or without bounds checking depending your needs. And it's very efficient. > - Casting Type conversions are very strict in c++ for non primitive types. And you can choose to forbid implicit conversions between ADT (this is the default) > - Unnecessary dynamic errors (things that could be statically check > at compile time instead). Such as? > - Everything is externally available (or at least, within the namespace), > which leads to unwanted module interactions/conflicts. It is true C++ lacks packages... > - implied conversions I answered to this. > - weak enumeration types Why? Enum are a different type in the system. > > All this is just the tip of the iceberg. For a fuller description of C++'s > problems (apart from the Ada comparison), see "Handbook of Programming > Languages", Volume 1., MacMillan Technical Publishing (I don't have the book > here, so I don't have ISBN). There's quite a description of C++'s problems > there, which don't address all of the inherited problems of C. Put the two > together, and you have one whopping list of problems. > > In the final analysis, we're not really talking about a specific > feature comparison here anyway. We're really just > comparing how the languages and the compilers of same such compare. > How they permit the user to develop quality software, and of course within > reasonable time frames. > > Sure, there are "techniques" that can be used to _reduce_ exposure, or > enhance type safety etc. But this is generally lame by comparison to > what the Ada language enforces. Another way to say this might be to > suggest that Ada enforces the "techniques". > > So if we're still talking about "productivity", it still > must be compared over the whole life cycle of the code. Not just > "delivery" of the code. There are no sufficient "productivity gains" > in the C++ language that will bail itself out of the cost of > debugging and troubleshooting the product later. > > Regarding "common applications" : > ================================= > > Unless you're talking about quick 'n dirty, throw away code, > I don't think you can dispense with the need for reliable code. > Especially if I am paying you to deliver me as much. > > Look at the Windows code crashes/seizures etc., > it's surprises, or when it does not deliver on functionality > that it is supposed to. > > Netscape/Explorer are two other big applications that > could greatly benefit from being developed in Ada95. Ada will not > make all of these problems go away, but the original point was that > CPU cycles will be expended by the Ada compiler to help the developers > of these projects, to identify problems before they occur. BEFORE, > testing begins. > > Consider which approach you would use below? > > The C/C++/Java approach : > > 1. Build hang glider > 2. Flight test it > 3. If you live through the test, fix test identified bugs. > 4. Repeat 2 and 3 as required > > Or.. > > The Ada approach : > > 1. Build hang glider > 2. Fix identified bugs > 3. Repeat 2 as required > 4. Flight test I guess you will agree the development process is not inherent to the language. You can build clean software in C++ or Java using the good methods, as well as in Ada. > > The 2nd approach is much safer, and is over the whole life cycle > of the project, is much cheaper. If we can't agree on that, > then we won't agree on much else ;-) In the field I work (videogames), this is not the case, but I have planned in more critical domains (though not that critical), and I understand those constraints. I do think the main difference is that people who program in Ada are less numerous and therefore more competent than the vast majority of C++ developers. > > Anyway, WRT the subject line "Ada the Best Language?", I don't think > that you can mandate a "best" unless you identify the application, and > the user. This is like saying "what is the best car to buy?" However, > I do believe that Ada is a better choice for _many_ software > applications today. I think it is starting to get more recognition > in light of this, also. > > wwg. The subject line was not mine, I was just making the point that many people criticizing C++ don't know much of it.