CPP "problems" (was Re: why has Cray dropped CPP support from cf77?)

[David E. Bernholdt]

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