• Choose a category
• All
• Classic-Fiction

a = average(p,q);

gets replaced with:

a = ((p+q)/2);

You have to be careful how you define the macro because it literally replaces the pattern located by cpp. For instance, if the macro definition said:

#define multiply(a,b) (a*b)

and you invoked it as:

c = multiply(x+t,y+v);

the resulting expansion would be x+t*y+v — probably not what you intended.

If you are a C programmer you may be using macros without being conscious of it. Many C header files (.h) contain macro definitions. In fact, some “standard” C library functions are really defined as macros in the header files. For instance, the function getchar can be linked in when you build your program. If you have a statement:

#include

in your file, getchar is replaced with a macro definition at compile time, replacing the C library function.

You can make cpp macros work for FORTRAN programs too.[38] For example, a FORTRAN version of the C program above might look like this:

#define AVERAG(X,Y) ((X+Y)/2)

C

PROGRAM MAIN

REAL A,P,Q

DATA P,Q /50.,100./

A = AVERAG(P,Q)

WRITE (*,*) A

END

Without a little preparation, the #define statement is rejected by the FORTRAN compiler. The program first has to be preprocessed through cpp to replace the use of AVERAG with its macro definition. It makes compilation a two-step procedure, but that shouldn’t be too much of a burden, especially if you are building your programs under the control of the make utility. We would also suggest you store FORTRAN programs containing cpp directives under filename.F to distinguish them from unadorned FORTRAN. Just be sure you make your changes only to the .F files and not to the output from cpp. This is how you would preprocess FORTRAN .F files by hand:

% /lib/cpp -P < average.F > average.f

% f77 average.f -c

The FORTRAN compiler never sees the original code. Instead, the macro definition is substituted inline as if you had typed it yourself:

C

PROGRAM MAIN

REAL A,P,Q

DATA P,Q /50.,100./ A = ((P+Q)/2)

WRITE (*,*) A

END

By the way, some FORTRAN compilers recognize the .F extension already, making the two-step process unnecessary. If the compiler sees the .F extension it invokes cpp automatically, compiles the output, and throws away the intermediate .f file. Try compiling a .F on your computer to see if it works.

Also, be aware that macro expansions may make source lines extend past column 72, which will probably make your FORTRAN compiler complain (or worse: it might pass unnoticed). Some compilers support input lines longer than 72 characters. On the Sun compilers the –e option allows extended input lines up to 132 characters long.

Procedure Inlining

Macro definitions tend to be pretty short, usually just a single statement. Some- times you have slightly longer (but not too long) bits of code that might also benefit from being copied inline, rather than called as a subroutine or function. Again, the reason for doing this is to eliminate procedure call overhead and expose paral- lelism. If your compiler is capable of inlining subroutine and function definitions into the modules that call them, then you have a very natural, very portable way to write modular code without suffering the cost of subroutine calls.

Depending on the vendor, you can ask the compiler for procedure inlining by:

Specifying which routines should be inlined on the compiler’s command line

Putting inlining directives into the source program

Letting the compiler inline automatically

The directives and compile line options are not standard, so you have to check your compiler documentation. Unfortunately, you may learn that there is no such feature (“yet,” always yet), or that it’s an expensive extra. The third form of inlining in the list, automatic, is available from just a few vendors. Automatic inlining depends on a sophisticated compiler that can view the definitions of several modules at once.

There are some words