Re: why still use C?

In comp.lang.c.moderated P.J. Plauger <[EMAIL PROTECTED]> wrote:
> "Hans-Bernhard Broeker" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]

[...]
> > running, and they want to be sure that changing the FPU doesn't affect
> > the results.  Not even minimally.  Result was that they decided to
> > re-configure the Intel FPUs to turn of their "excess" precision.
> > These guys would be *very* upset if a compiler came out that no longer
> > supported binary FP.

> This is the kind of simplistic thinking I was referring to when I
> wrote (and you clipped):

> : Perhaps you're thinking of the constituency who think the `right'
> : answer is the one that reproduces all the noise digits exactly
> : from the original test run. Not much help for them.

Going over your arguments again, I concede your point.  Sorry if I
came across as being mule-headed.  Germans from the region of the
country I come from _do_ have a tendency to be quite stubborn...

> I remember when Princeton University upgraded their IBM 7090 to an
> IBM 7094, which would trap on a zero divide instead of effectively
> dividing by one. After one week of production code bombing regularly,
> the user community *demanded* that the divide check trap be left
> permanently disabled. They just didn't want to know...

Well, the new hardware should have offered to silently return infinity
instead ...

> > I see no problem adding new features to the language.  But the day you
> > start removing features is when you may be causing real trouble for
> > people out there.

> Who's talking about removing features? Standard C has *never* promised
> that floating-point arithmetic will be done in binary. 

You're right of course, C never promised that.  It's the hardware
designers who effectively did that.  I'm not aware of any architecture
in active use right now that has FLT_RADIX != 2.  In fact, there seems
to be hardly anything else but IEEE 754 (with its extensions) out
there these days.

Given that, programmers did start to rely on this de-facto standard,
and would at least somewhat justifiably be opposed to any change if
that caused extra work for them.  Since that change would only come to
them with the next generation of hardware, though, users can still
vote against it with their hardware investments, so no harm done.

> And it's damned hard to write a program that can determine whether
> it is.

Unless it is allowed to just look up FLT_RADIX in <float.h>, that is ;-)

[...]

> Exactly. That's *so* much more work than simply fleshing out good
> support for 754R *if present* that it's really worth avoiding, if at
> all possible. I want to explore thoroughly the implications of *not*
> having Standard C support multiple floating-point formats
> simultaneously, before we commit to adding all that complexity to C.

I agree.  So the issue boils down to this question:

  How likely is a single program going to really need both decimal and
  binary FP?

If and only if the answer to that is "essentially never", then there's
nothing to do --- let the compiler vendors and platform ABI designers
make the decision on a per-program basis, and thus outside the realm
of standard C.

-- 
Hans-Bernhard Broeker ([EMAIL PROTECTED])
Even if all the snow were burnt, ashes would remain.
-- 
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]