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 X-Google-Thread: 103376,b30bd69fa8f63cb2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-13 08:07:02 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: kanze@gabi-soft.fr Newsgroups: comp.lang.ada Subject: Re: C bug of the day Date: 13 Jun 2003 08:07:02 -0700 Organization: http://groups.google.com/ Message-ID: References: <1054751321.434656@master.nyc.kbcfp.com> <20619edc.0306121040.2fea0695@posting.google.com> <3EE8CE83.8090001@attbi.com> NNTP-Posting-Host: 62.160.54.162 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1055516822 14242 127.0.0.1 (13 Jun 2003 15:07:02 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 13 Jun 2003 15:07:02 GMT Xref: archiver1.google.com comp.lang.ada:39122 Date: 2003-06-13T15:07:02+00:00 List-Id: "Robert I. Eachus" wrote in message news:<3EE8CE83.8090001@attbi.com>... > Mike Silva wrote: > > Yes, it seems like the objection is that Ada doesn't "solve this > > problem" because at some point a programmer will actually have to > > write code, and that code may have bugs. True, but nothing to do > > with "all of the defaults were fundamentally safe." > Sort of "agreeing violently" with Mike... > The goal in Ada is for as many bugs as possible to be caught by the > compiler. Is it possible for the compiler to catch all bugs? Of > course not. But based on my experience at least, Ada does catch > around 99% of all bugs by the time you have a clean compile. That of > course requires that when you see an "unexpected" compiler message, > you think about what it means, rather than just papering it over. Up until there, I could say the same thing about C++. But that's because I know what to avoid, and pay very careful attention. In most languages, if you are programming carefully, most errors will be typing errors. In this regard, of course, C++'s use of a lot of symbolic operators doesn't help; a one character error is likely to result in a different legal operator. But most of the time, it will be an inversion of characters in a name, or something like that. And C++ also complains if you use an undefined symbol. I think the real argument is more along the lines of how difficult is it to program carefully. I think another real argument (which hasn't been mentionned) is how transparent the working code is. > For example, if GNAT tells me that no function Foo is directly > visible, but there is one at Ada.Bar.Foo, there are two cases. One > is, "Of course I meant that one, just thought I had a use clause." > The other of course is that I was thinking of some other function > entirely. I would hate to have a compiler that "fixed" the reference. > At least 90% of the time it would be right, but the compiler has no > way to know which 90% that is. I don't know of any compiler which does that, in any language. Today, because I seem to recall having seen some 20 or 30 years ago. When you turn your punched cards in in the evening, to get the results back the next morning, you might appreciate such a feature, provided the compiler did say what it did. In today's environments, of course, where you never actually invoke the compiler, but some sort of advanced (or not so advanced) build system, it would be a disaster. -- James Kanze GABI Software mailto:kanze@gabi-soft.fr Conseils en informatique orient�e objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16