Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mit-eddie!ll-xn!ames!pasteur!helios.ee.lbl.gov!lll-tis!lll-winken!arisia!quintus!ok From: ok@quintus.uucp (Richard A. O'Keefe) Newsgroups: comp.lang.fortran Subject: Re: Fortran vs C for computations Message-ID: <400@quintus.UUCP> Date: 14 Sep 88 07:31:10 GMT References: <391@quintus.UUCP> <3494@lanl.gov> Sender: news@quintus.UUCP Reply-To: ok@quintus.UUCP (Richard A. O'Keefe) Organization: Quintus Computer Systems, Inc. Lines: 79 In article <3448@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >People keep saying that Fortran has no preprocessor. This is _not_ >true. Preprocessing is a textual substitution problem. It can be done >on _any_ sufficiently powerful text editor. Not only that, cpp can usually >be applied to any text file you have - including Fortran code. In article <391@quintus.UUCP>, I wrote several reasons why cpp cannot in fact be used on >Fortran< code (though it isn't too shabby for Ratfor). In article <3494@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Gee, because cpp is not _universally_ applicable to Fortran this means >Fortran _can't_ be preprocessed at all. I gave cpp as an example, not >_only_ possibility. I still stand by my original statement: Fortran >_can_ be preprocessed! I do it all the time. I did not say that "Fortran cannot be preprocessed at all". My posting attacked quite specifically Giles' claim that "cpp can be applied to ... Fortran code". For example, the UNIX f77 compiler will call cpp for you, but this is not always useful. Here is a toy example: tr ">" "\011" <zabbo.F #define HAIRY(A,B,C) (A+B+C+A+B+C+A+B+C+A+B+C+A+B+C) >REAL FUNCTION VECSUM(FLTVEC) >REAL FLTVEC(3) >VECSUM = HAIRY(FLTVEC(1), FLTVEC(2), FLTVEC(3)) >END EOF f77 -c zabbo.F That works. But sed -e 's/>/ /' <zabbo.F ~~~as before~~~ produces error messages from the f77 compiler: Error on line 4 of zabbo.F: unbalanced parentheses, statement skipped Error on line 4 of zabbo.F: Execution error unclassifiable statement Wizards will at once realize what the problem is. If you want to use cpp as your preprocessor with f77, you *cannot* use standard Fortran layout. No discredit to cpp, it is meant for C after all. I have seen the guts of several statistics packages which were written in Fortran, and they were totally dependent on preprocessing for their portability. Only snag was, *first* you had to port the preprocessor. >Also: this statement (3) contains the assumption that preprocessing >_must_ be done on the same machine as compiling. I'll concede this one, though I'd point out that I did avoid assuming that you compile on the machine you run on. Giles has in mind the situation where he is using a fairly powerful workstation and pushing code to other machines. This is nice PWB-type stuff. I have in mind situations where I write a program on my machine and give the source code to other people, where it may be quite impossible for me to do the preprocessing on my machine. For example, writing a C program under 4.2BSD with due care and attention given to portability, and constant checking of the SVID to ensure that the program _ought_ to port to V.2, but where I cannot do the preprocessing on the 4.2BSD machine because I haven't got the necessary header files. Can we agree on the following statement about preprocessing: You need the same preprocessor on each preprocessing-host, and the preprocessor on a particular preprocessing-host has to know enough about each compiler and target computer which that preprocessing-host is used with. (E.g. if I do my preprocessing on a Sun, my compilation on a Sun, a Vax, and a Sequent, and my execution on a Sun, Vax, Cray, Fujitsu, and Cyber, then my preprocessor has to know about 3 compilation environments and 5 execution environments.) I am not arguing that preprocessing needs to be part of the Fortran language standard, but I do claim that a preprocessor for Fortran should be designed for Fortran, not C, and should either be at least as standardised as pre-ANSI C or should be provided to users in source form.