comp.lang.ada
 help / color / mirror / Atom feed
From: Jonathan Guthrie <jguthrie@brokersys.com>
Subject: Re: An interesting object lesson (Ada vs C)
Date: 1998/05/01
Date: 1998-05-01T00:00:00+00:00	[thread overview]
Message-ID: <6ico4n$dpf$1@news.hal-pc.org> (raw)
In-Reply-To: dewar.893645616@merv


In comp.lang.ada Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> <<In the C world, "really knows what he is doing" means "knows how to turn
> 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.





  parent reply	other threads:[~1998-05-01  0:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-04-26  0:00 An interesting object lesson (Ada vs C) Robert Dewar
1998-04-26  0:00 ` Jonathan Guthrie
1998-04-26  0:00   ` Robert Dewar
1998-05-01  0:00     ` Jonathan Guthrie
1998-04-26  0:00   ` Robert Dewar
1998-04-29  0:00     ` Keith Thompson
1998-05-01  0:00     ` Jonathan Guthrie [this message]
1998-04-26  0:00   ` Al Christians
1998-04-30  0:00     ` John McCabe
1998-04-26  0:00 ` Andi Kleen
1998-04-27  0:00   ` Samuel Tardieu
1998-04-27  0:00 ` Aaro Koskinen
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox