C vs. FORTRAN (was C official DOD langauge?)

[Charles Noren]

I've been getting additional e-mail about a C vs. FORTRAN
comparison list.  I may have betrayed a language bias which
I don't want to do, additionally I've been making unfair
comparisons of old FORTRAN compilers to modern C compilers.

The risk of comparing languages is the tendency to start
religious holy wars in support of one language over another.
This certainly was not the intent of the orignal asker nor do
I want to do that.  What I'm trying to do is stick my neck out
with raising a few ideas and solicit comment from the network
to help the orignal poster to make an intelligent decision of
whether or not move from FORTRAN to C.  I would say the answer
is not obvious to me (I welcome e-mail flames and will summarize
to my best the important points -- as you can probably tell, I'm
no compiler guru).  Also, take whatever I say with a grain of
salt.  I have a bias towards C and the comments may reflect this
(and, I should note, my bias does not have entirely rational
causes).

This discussion probably does not fit the charter of comp.lang.c
so I'm directing follow-ups to comp.lang.misc.

I was an old user of FORTRAN, FORTRAN IV in fact.  Modern FORTRANs
have evolved over time and thus some of the things I listed as C
advantages are also found in modern FORTRAN compilers.  These, I'm
told, include:

Modern FORTRAN enhancements:

 1.  Data Structures.  FORTRAN IV did not have them, modern
     FORTRAN compilers do.
 2.  Cleaner code structures.  Apparently the newer FORTRAN
     compilers have modern code structures.  As one person
     noted, his FORTRAN code is essentially free of statement
     labels and indented for readability.
 3.  Recursive subroutine calls.  Most, if not all, modern
     FORTRAN compilers can call subroutines recursively.
     This is many a feature of the underlying implementation
     of how arguments are passed to subroutines/functions.
     (Question to langauge definition guru's: Are recursive
     and reentrancy issues specified in the formal langauge
     specifications of C and FORTRAN?)
 4.  Free form code.  Modern FORTRAN compilers allow for free
     form entry of code, with similar restrictions that apply
     to C code with its pre-processor statements (e.g., #define).

And now a C advantage list.

C Advantages over FORTRAN:

 1.  Data Pointer Types.  FORTRAN apparently still does not
     have a pointer type.  Underlying argument passing
     mechanisms in FORTRAN subroutines probably use pointers,
     but the language definition does not have a data pointer
     type.  Data pointers conveniently allow referrences to
     physical memory (useful for microprocessor controllers,
     perhaps not useful for virtual memory machines) and the
     "more natural" creation and maintenance of some data
     structures such as linked lists.
 2.  Function Pointer Types.  One person commented that it is
     possible to pass a single function explicitly in FORTRAN,
     but a "table" of pointers to functions cannot be created
     created in FORTRAN.
 3.  Ability to have variable argument lists.  As some have
     pointed out, this feature in C is somewhat awkward
     (this is in the eye of the beholder) and thus not
     considered by some as a major advantage.
 4.  Macros.  In most C implementations, macros are expanded
     in seperate program from the actual C compiler, known as
     the C Pre-Processor (cpp).  One person suggested that
     FORTRAN code could be run through cpp an thus have macros.
     I have not tried this, but it is an interesting idea.
 5.  Dynamic memory allocation.  f77 does not have this, but
     apparently f9x will have dynamic memory allocation.

FORTRAN Advantages over C:

 1.  Lack of pointer types.  Pointers in C (and how their
     relation to and distiction from arrays) often are a 
     stumbling block to new C programmers (and sometimes 
     old C programmers).
 2.  FORTRAN environments probably have more mature math
     libraries.  Some C programmers pointed out that they
     link to some FORTRAN math libraries.
 3.  Fortran compilers have been around longer and are
     generally better at optimization than C compilers.
 4.  The Fortran language is designed so that compilers
     can make useful assumptions for code optimization,
     which cannot be made for C compilers.  Two examples:
      a.  Aliasing is not permitted in Fortran.
          For instance, if you declare two array arguments in
          a Fortran subroutine, those arguments cannot be the
          same array -- if they are read and write arguments.
          This permits the subroutine to be compiled
          with very fast vector instructions (on machines that
          support vectorization such as Crays).
          (One person mentioned that there are are good ways
          for compilers to get around the aliasing problem --
          so this is not such a disadvantage to C.  I must
          say that I plead ignorance here.)
          (Question:  It's been so long since I've used
          FORTRAN, but how does the EQUIVELANCE statement
          affect or not affect aliasing?)
      b.  The C for statement does not have a well defined
          "control variable" and thus cannot be automatically
          vectorized.
 5.  *Natural* array subscripts in C must start with zero, 
     which for some is counter intuative (of course the C 
     programmer might ask what is so intuative about starting 
     with 1 ;-)).  One person mentioned this can cause 
     optimization problems by defeating alias optimizations in 
     C, again I don't know if this is the case.  Modern FORTRAN
     compilers, I'm told, allow for subscripts to start at
     any value (including negative integer values).  Several
     people reminded my that C arrays do not have to be zero
     based.  With macros and pointers one could use any integer
     value in an array reference.  However, it would seem that
     FORTRAN, with its way specifying a starting index (if it
     truely is part of "standard" FORTRAN and not just a vendor
     language enhancement) has the advantage here.
 6.  C does not permit multidimensional array parameters of
     different sizes.  C is certainly powerful enough the
     work around this, but it does not have the built-in
     stuff that FORTRAN has (with its possible built-in
     optimization).
 7.  C does not have the COMPLEX data type.  Of course
     through data structures this kind of thing could be
     implemented in C.  However, it is built-in in FORTRAN,
     with libraries already built to support it, and
     probably built-in optimization.
 8.  C has somewhat confusing reserved word adjectives
     for storage classes, which also vary in meaning depending
     on the context.  A classic example is the C reserved
     word "static".  It has an aspect of meaning "unchanged"
     in that variables declared as such inside functions
     retain there last value from function exit and the
     next invocation of the function.  "static" also has the
     meaning of global only the to module file the "static"
     function or "static global" data resides (in other words
     its local to that file).
 9.  Dynamic memory.  Due to the use of pointers in C,
     dynamic memory is used often in C.  How and when to use
     dynamic memory (and which are the best dynamic memory
     functions) can cause debate with C programmers.  With the
     use of dynamic memory come subtle bugs (memory leaks) which
     can be hard to trace.


I have certainly missed some points and corrupted others.
Flames and comments are welcome.

Thanks to the following people whose comments I've
incorporated (but don't blame them for my errors):

 o  Andrew Mullhaupt (mailrus!uunet!Morgan.COM!amull)
 o  a person from Microsoft (whose name I could not locate in
    the mail header).
 o  John Sahr (thalatta.com!calvin!johns at cs.utexas.edu)
 o  another person I could not identify from the mail header.
 o  Roger Cole (cole at luke.lanl.gov).
 o  Dan Bernstein (brnstnd at stealth.acf.nyu.edu).


-- 
Chuck Noren
NET:     ncar!dinl!noren
US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260,
         Denver, CO 80201-1260
Phone:   (303) 971-7930