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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b8effe21a2a8e1cb X-Google-Attributes: gid103376,public From: Jonathan Guthrie Subject: Re: An interesting object lesson (Ada vs C) Date: 1998/05/01 Message-ID: <6ico4n$dpf$1@news.hal-pc.org>#1/1 X-Deja-AN: 349337435 References: <6hvpf2$77d$1@news.hal-pc.org> Organization: Information Broker Systems Internet Services Newsgroups: comp.lang.ada Date: 1998-05-01T00:00:00+00:00 List-Id: In comp.lang.ada Robert Dewar wrote: > < the warnings on". Do the student a favor and introduce him to lint and > -Wall. > >> > Yes, of course, but the point is that having to rely on warnings for such > very basic type consistency checking is *exactly* the weakness that this > example pointed out (if you think all C compilers come with such warnings, > you have been lucky :-). No, I have used a tremendous variety of C compilers. Some have good warnings, some don't. In particular, gcc checks this pretty well. However I haven't seen that particular warning given by any other compiler. That's why I mentioned lint. That's widely available and has caught that particlar kind of error for 20 (or so) years. (Unfortunately, it tends to complain about things like ignored returned values, that generally are not a big deal.) The thing is, that type of parameter string/passed parameter mismatch is determinable to be incorrect by static semantic checking. (There are other errors, however, involving similar functions, that are not possible to analyze using static semantic checks.) My point is that you need to make use of all available tools when you have a problem, whether they're built in to the compiler or not. Of course, it is possible to design a language that doesn't have this kind of weakness, but the guys who did C did a pretty good job with the I/O considering the situation WRT the language design arts of the late 60's. (Of course, they had it easy. They stole the system from FORTRAN. It was the FORTRAN guys, working in the late 50's that actually invented this approach to formatted printing.) > Someone else complained at the use of the non-standard long double, true, > but it seems a pity that you *need* a non-standard extension to get at > a basic facility of the underlying architecture -- certainly not something > that is required in Ada! First off, "long double" is not non-standard. It was added by the ANSI C committee in the mid 80's. It is now part of the official ISO C standard, and has been for about a decade. I suspect that since the "long" size modifier for floating-point values isn't used very much because it isn't used very much. I certainly had no idea that it was standard until I looked it up. (I was going to complain about the non-standard extension myself.) Secondly, while I understand (I'm interested in Ada, even though I've never written a program in it) that Ada allows you to specify the sizes of the various types are, I would expect the compiler to have considerable leeway to determine how the operations are done. I would expect the compiler vendor to trade off between performance and portable calculations. -- Jonathan Guthrie (jguthrie@brokersys.com) Information Broker Systems +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA We sell Internet access and commercial Web space. We also are general network consultants in the greater Houston area.