On Mon, 25 Aug 2008 10:17:08 -0800, glen herrmannsfeldt
ugcs.caltech.edu> wrote:
> Kevin G. Rhoads wrote:
> (someone wrote)
>>>Is there any chance that you might list some of these design
>>>principles where C made the wrong choice and fortran made the
>>>right choice?
>
>> Don't know if James will, but here are a few:
>
>> Wild pointer errors -- C is prone, Fortran is immune.
>
> Is Fortran really immune? If you call a routine with
> an uninitialized pointer does the standard require it
> to be caught?
>
Or a stale pointer -- just as easy in Fortran as C. The one semantic
difference is that in plain Fortran you can't as easily _create_ a
pointer that is bogus from birth -- and with common but not standard
"Cray" pointers Fortran has that "feature" too.
But another difference is that an awful lot of useful problems can be
done in Fortran with no (visible) pointers whereas they can't in C, so
in C you have more _opportunities_ for pointer bugs; the risk per
instance is roughly the same but it's multiplied by a much larger N.
>> Over-run string storage -- C is prone, Fortran less so.
>
> Less so, I will agree with.
>
Yep. Personally I would say much less -- but still not zero.
>> Handling of mismatched declare/invoke argument lists --
>> C mucks up the stack, tends to go off to la-la,
>> Fortran's handling is more graceful.
>
Both original "K&R1" C and classic FORTRAN (thru 77) put all the
burden on the programmer, and any mistake can be catastrophic. C89 and
F90 provided new, safe ways (prototypes and explicit interfaces) but
retained the old ones for legacy. I call that a tie.
> I don't understand this one. C pretty much requires
> the caller to pop the stack. (Varargs routines allow
> a variable number of arguments.) Fortran allows
> the callee to pop the stack. Using a special form
> of RET in the 8086 instruction set, it takes one
> less instruction. Most now use the C convention, though.
>
Although standard C requires that vararg routines be declared
specifically (with a prototype using ellipsis "...") precisely so that
they _can_ use a different calling mechanism -- and I have used a
system where they do, so that the non-vararg case can conform to that
machine's normal (multilanguage, fixed-frame) mechanism.
>> MULTI-DIMENSIONAL ARRAYS -- C does NOT have these, it
>> has a grody work-around
>
> There are questions about names, but most agree
> that C has multidimensional arrays. In C89, the
> dimensions must be constants.
>
>> Variable dimension Multi-dimensional arrays -- C doesn't
>> even have a grody workaround -- you want 'em, you code
>> 'em
>
> I believe fixed in C99.
>
Concur both; the notation isn't quite as nice, but it works.
C (still) doesn't have array _operations_ (any rank) (except
C considers str*/mem* operations rank1 array of char),
but neither did FORTRAN (much) before 90.
>> C enforces a stack-oriented, twos-complement view -- if
>> the hardware differs, well, fake it or force it; Fortran
>> is more architecture neutral
>
> I don't understand this one. C doesn't enforce a stack
> any more than Fortran. It does require the ability
> to do recursion, and a stack is a popular implementation.
>
And the C standard explicitly allows non-2sC, although it does require
binary, for integers. Some C _program(mer)s_ do assume and rely on
(the bitpatterns for) 2sC -- but so do some Fortran ones. (C, like
Fortran, doesn't even require binary for floating.)
>> C, as a language, is almost uselessly spare -- without the
>> C standard library it is really not much more than PDP-11
>> HLA with a thin veneer. OR, do you, like most people consider
>> the C standard library part of the language? It isn't really,
>> not in the strict sense -- but most people think of it as if
>> it were. Fortran defines a complete language as the language.
>> Some people may consider this difference a feature for C, but
>> "roll your own library to use the language" does not make
>> for portability, readability or maintainability.
>
> The library is part of the standard. Do you mean the difference
> between doing I/O with statements or with function calls?
> The library is part of the language enough that library
> names are reserved, as are all names starting with str even
> if the language doesn't yet use them.
>
Concur. (Not quite _all_ str*, but most, also most to* and is*.) It's
true that most of C's "core" language was defined first, and the
library added in stages -- but (early) FORTRAN's library also started
pretty small and grew over time; and it has also made what I consider
more extensive changes in the core language part.
In fact Fortran arguably provides a little more language-library
separation because you can standardly override a library _name_ by
declaring your own EXTERNAL; C doesn't guarantee this, although
many implementations as an extension sort of support it more or less.
(If that sounds like a pretty weak reed, it is.)
>> C normally requires LINT to do checking that Fortran
>> compilers do.
>
> Most compilers now do it. That is more the unix separate
> small utilities philosophy.
>
>> And, of course, the classic -- C forces everything double for
>> computation, control over numerics is minimal, Fortran was
>> designed to do numerics right.
>
> This changed with the ANSI standard in 1989. The usual
> x87 implementations do it anyway, though. The Fortran
> requirements for floating point arithmetic have been
> discussed here before.
>
And C99 adds a good bit more, including a portable option for IEEE.
(That is, it is optional for an implementation to support IEEE, but if
it does so, which the source code can detect during preprocessing,
the access to rounding, exceptions, and such is standard.)
And
-- finally! -- complex.
- formerly david.thompson1 || achar(64) ||
worldnet.att.net
