lamonts@Sds.Sdsc.EDU (01/24/88)
Herman Rubin <cik@l.cc.purdue.EDU> says
> I find that I can do much better mathematical programming in C than in
> FORTRAN. By better programming, I mean that I can use constructs in C
> which are convenient and produce efficient code, and which FORTRAN does
> not know the first thing about. The only advantages of FORTRAN are the
> power operator and multi-dimensional arrays. The major disadvantages are
> the lack of indirection and casting, and the requirement that a function has
> an argument. Also C lets you use the rest of the instruction set (although
Wrong, oh, binary breath... ;-)
There are whole bunches more reasons for using FORTRAN for *certain*
applications than just power operators and multi-dimensional arrays. The
COMPLEX data type, f'rinstance. Yes, I know that you can code some sort
of bletcherosity in C to handle complex numbers, but there are no intrinsic
functions which will handle them conveniently (in fact, there are no
INTRINSIC functions, in the FORTRAN sense at all in the C language, at least
as far as I interpret the term.... please feel free to correct me if I am
mistaken...;-) ).
I don't see the lack of indirection as a major disadvantage in the type of
programs FORTRAN is suited to. Perhaps I am missing the point here. Can
someone please illuminate the subject?
Within the limited set of data types available in the old Dinosaur, there are
appropriate "cast" operators, if you can think of
blat = float( i )
as a form of cast.
Finally, just to beat the subject completely to death, if you really insist
upon having functions with no arguments (rather than a SUBROUTINE call),
the following appears to be valid code:
program foo
blat = bar()
print *, 'This worked! Blat is ', blat
stop
end
real function bar()
bar = 1.0
return
end
I won't swear on a stack of K&Rs that it is in the standard, but it worked on
all of the compilers that I could run it on, including the Cray CFT 1.14
compiler, which is annoyingly ANSI conformant.
But what about
void bar()
do I hear you ask? Use
subroutine bar
which is as close to "function returning void" as I can imagine. In fact, in
light of some other comments that I've seen on this group, the construction
call bar
is slightly more aestheticly pleasing than
bar();
In some ways, FORTRAN actually *wins*. For example, named COMMON seems to me
to be a better way of handling external variables than simply hanging them out
in space. The only disadvantage that I seen in COMMON is that names of things
in COMMON can be different between subprogram units, making the code harder
to understand. It is, however, a neat (in both senses of the word) way of
logically grouping externals.
Yes, FORTRAN does run like a slug on some systems. That alone may militate
against using it over C. But, please, don't malign a very useful and, need I
say, venerable language.
spl
----------------------------------------
Internet: LAMONTS@SDS.SDSC.EDU
Bitnet: LAMONTS@SDSC
Span: SDSC::LAMONTS (27.1)
USPS: Steve Lamont
San Diego Supercomputer Center
P.O. Box 85608
San Diego, CA 92138
AT&T: 619.534.5126gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/25/88)
In article <11440@brl-adm.ARPA> lamonts@Sds.Sdsc.EDU (Steve Lamont) writes: >... (in fact, there are no >INTRINSIC functions, in the FORTRAN sense at all in the C language, ... ANSI C will permit most standard library functions to be implemented as intrinsics, with the additional feature that there is a way to guarantee that an actual library function is used when necessary. /* <string.h> extract: */ void memcpy( char *d, const char *s, int n ); #define memcpy( d, s, n ) __BLOCK_MOVE( n, s, d ) /* above is a compiler intrinsic */ /* ... */ /* application code extract: */ memcpy( a, b, i ); /* expanded in-line by compiler */ /* ... */ #undef memcpy fill( p, sizeof *p, memcpy ); /* pass function pointer */ >For example, named COMMON seems to me >to be a better way of handling external variables than simply hanging them out >in space. The only disadvantage that I seen in COMMON is that names of things >in COMMON can be different between subprogram units, making the code harder >to understand. It is, however, a neat (in both senses of the word) way of >logically grouping externals. The possibility of disagreement in the COMMON variables among FORTRAN subprograms is a frequent cause of bugs. If you want to do something analogous in C, you can use an extern structure to package the data under a single visible name. Actually, inter-module communication via global data is contrary to well-established structured design principles. It should be used sparingly or not at all.
hydrovax@nmtsun.nmt.edu (M. Warner Losh) (01/27/88)
In article <11489@brl-adm.ARPA>, dsill@NSWC-OAS.arpa (Dave Sill) writes: . In article <88012145556.2040246a@Sds.Sdsc.Edu> Steve Lamont . <lamonts@Sds.Sdsc.EDU> writes: .> [COMMONs are great] . . That's funny, if you had asked me to list of what I think are . Fortran's 10 biggest mistakes, COMMON blocks would probably be at the . top. They are probably the single largest cause of suicide among . Fortran maintenance programmers, although implicit variable . declarations might be close. And I alway thought that ASSIGNed GOTOs were on the top of that list. :-) -- bitnet: lush@nmt.csnet M. Warner Losh csnet: warner%hydrovax@nmtsun uucp: ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!hydrovax Warning: Hydrovax is both a machine, and an account, so be careful.