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.
bernhold@qtp.ufl.edu (David E. Bernholdt) (02/21/91)
In article <1108@riscsm.scripps.edu> mikec@scripps.edu (Mike A Christensen) writes: >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. If this is the case, I'm not suprised "we" have a misunderstanding. When I invoke cf77 4.0 on my local YMP running unicos 5.1 as 'cf77 -c -dp mchprm.F', I get the following messages: Warning: -d option is being deleted; Use -Wf option. WARNING! C Preprocessor support in cf77 will be deleted in next release. Notice how in the case of -dp, it tells me to look for an alternative, while it simply says CPP support is being deleted. Period. What is one supposed to think? If they really are replacing CPP with an equivalent, why say its being deleted? If there are less subtle changes which the user will notice, but similar functionality will somehow be available, why say its being deleted? Why not include a section in the man page explaining the forthcoming change & refer cf77 users to it? The warning could say "changed" rather than "deleted", if that were appropriate. To my mind, they've done something stupid either way: Either they are removing support for a useful, common feature of unix systems, or they _said_ they were and didn't really mean it. Technically, it is not a substantial problem, as I've already modified my Cray makefiles to do the CPP step separately -- though it distinguished the rules from those on all of the other unix systems I work with and consequently requires special handling when I build or install codes. My concern is with the philosophy behind the decision and what it might indicate about the future of unix on Crays. This appears to be a step _away_ from the homogeneity across different systems which has been developing over the years. When you develop and run large codes on numerous different machines, homogeneity of the user environment can be _very_ important in keeping one's sanity! -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365