CPP "problems" (was Re: why has Cray dropped CPP support from cf77?)
David E. Bernholdt
bernhold at qtp.ufl.edu
Tue Feb 19 05:11:00 AEST 1991
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 at convex.com> patrick at 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 at qtp.ufl.edu
Quantum Theory Project bernhold at ufpine.bitnet
University of Florida
Gainesville, FL 32611 904/392 6365
More information about the Comp.unix.cray
mailing list