Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <14205@lambda.UUCP>
Date: 23 Jan 90 02:34:33 GMT
References: <15913@boulder.Colorado.EDU>
Lines: 39

From article <15913@boulder.Colorado.EDU>, by ruede@boulder.Colorado.EDU (Ulrich Ruede):
> In summary, I believe that C gives me a chance to write better
> structured and more efficient code. FORTRAN does have some efficiency
> advantages in an array-dominated world, where memory structures and access to
> the memory is regular.

Yes, C has some advantages over Fortran.  The ones you mentioned:

Dynamic memory
struct types
small integers (or even char)
macros

Of these, the first two are provided (with better syntax and sometimes
better semantics) by Pascal, Modula2, ADA, etc..  Macros are better
provided as a separate preprocessor (which could even be written
to be independent of the target language).  Small integers and other
data types are also available in these other languages (but, due to 
strict type checking, are often difficult to use).

If suspect that you would really be happier with Fortran 90.  It has
dynamic memory (but NOT implemented using explicit pointers - so no
aliasing slow-down).  It has structs (called 'derived types' - same
thing really).  It has several different 'kinds' of INTEGERs, CHARACTERs,
REALs, etc..  In short, it has everything on your list but macros -
but they are mostly used in C to make the awful syntax more palatable.

> By the way, the authors of NUMERICAL RECIPES claim that aliased
> arguments are common coding practice in FORTRAN and use them systematically.

Aliasing is perfectly legal in Fortran, so long as none of the aliased
variables are assigned to.  I don't remember seeing any example in
NUMERICAL RECIPES that violated this rule.  The rule exists because
Fortran programs are required to have the same meaning in an imple-
mentation that uses call-by-reference as they do in an implementation
which uses call-by-value/result.  Programs meeting this constraint
may be optimized without fear of aliasing problems.

J. Giles