bernhold@qtp.ufl.edu (David E. Bernholdt) (02/19/91)
I don't want to start another thread (war?) on preprocessors, but I had to respond to Patrick's remarks... In article <1991Feb18.145116.3840@convex.com> patrick@convex.COM (Patrick F. McGehearty) writes: >... I do know that >while using cpp works as a preprocessor for many programs, it also >has weaknesses since the tokenizing rules for fortran and C are so >different. ... It is worth noting that this difference in blank significance is only relevant when using the macro substitution capabilities of CPP -- the include and conditional compilation features are all given with lines beginning '#' as their first non-blank character. The only possible confusion is if someone uses '#' as a continuation indicator, and since '#' isn't in the f77 character set, its as non-standard as using CPP. If one is aware of the capabilities & limitations of CPP, it can be a very useful tool. I don't council using _any_ tool without a pretty good understanding of what it is (supposed) to do and how. >A blanket decision to run CPP over large "dusty-deck" unstructured Fortran >programs can reach up and bite you without giving any indication of what >happened. Use with caution! This is probably also true of many other preprocassors people use with Fortran source. If they interpret (for example) comment lines in a certain format as preprocessor instructions, you may find a bad interaction with comments in the dusty-deck that _happen_ to have that format. Same result. Also note that most CPP implementations allow you to remove the definitions of all macros defined by default -- useful if problems do occur. -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365
john@ghostwheel.unm.edu (John Prentice) (02/19/91)
In article <1300@red8.qtp.ufl.edu> bernhold@qtp.ufl.edu (David E. Bernholdt) writes: >I don't want to start another thread (war?) on preprocessors, but I had to >respond to Patrick's remarks... > > [text deleted...] > >If one is aware of the capabilities & limitations of CPP, it can be a >very useful tool. I don't council using _any_ tool without a pretty good >understanding of what it is (supposed) to do and how. > I would second this comment. We used to use a rather sophisticated preprocessor for our Air Force hydro codes and we junked it when we started developing the next generation of codes because it was TOO sophisticated. People got too sexy with their preprocessor constructs and it got to where it was more a pain in the rear than a help. We went to CPP simply because it is virtually universially avaiable (anywhere C is). It is a pretty low level preprocessor, but quite sufficient to do what we need and keep us out of trouble. As for Cray dropping support, this shouldn't really be a big issue. You can always use the C version to process your Fortran. It is perhaps a bit more work to do, but not that much. We do this already on both our hydro codes and on my quantum mechanics codes. We just use make files that first call CPP and then the Fortran compiler. This particular approach is useful also because we run on a variety of systems and most don't support any Fortran preprocessors at all. On the other hand, they all have C. John -- John K. Prentice john@unmfys.unm.edu (Internet) Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA
dik@cwi.nl (Dik T. Winter) (02/19/91)
In article <1300@red8.qtp.ufl.edu> bernhold@qtp.ufl.edu (David E. Bernholdt) writes: > It is worth noting that this difference in blank significance is only > relevant when using the macro substitution capabilities of CPP -- the > include and conditional compilation features are all given with lines > beginning '#' as their first non-blank character. That is not the only possible problem. CPP is allowed to remove leading white space from a line. There is at least one CPP around that does that occasionally. Other problems that might occur are with quotes (both single and double). ANSI C preprocessors *must* look at them as starting string/ character constants, disallowing preprocessing within them. (But this is of course only a problem if you are using hollerith constants.) -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
mikec@scripps.edu (Mike A Christensen) (02/21/91)
I think we have a misunderstanding here, from my communication with Cray software development, they are REPLACING the functionality of CPP with a mostly equivalent (i.e. should take most C preprocessor directives) fortran preprocessor. This preprocessor will know about Fortran comments (especially ones that begin with CRAY in CC1...) and various other problems with using the C preprocessor on Fortran code. I did the same panic when I saw the comment from CF77 about ".F" files going away and not automatically running the C preprocessor, and it took me several phone calls to finally get what the "real" answer was.