Path: utzoo!attcan!uunet!husc6!mailrus!ncar!ames!amelia!lemming.nas.nasa.gov!fouts
From: fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran vs C for computations
Message-ID: <968@amelia.nas.nasa.gov>
Date: 7 Sep 88 22:24:02 GMT
References: <962@amelia.nas.nasa.gov> <3290@lanl.gov>
Sender: news@amelia.nas.nasa.gov
Reply-To: fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts)
Organization: NASA Ames Research Center
Lines: 72

In article <3290@lanl.gov> jlg@lanl.gov (Jim Giles) writes:

>Write the preprocessor in Fortran.  It is now as portable as the Fortran
>environment is.

But I don't want to write the preprocessor, I want to use the one that
comes standard with the language (;-)

>#ifdef is an admission that your compiler isn't any good.  If the
>conditional expression is a constant, a normal if statement should 
>be optimized so that code is only generated for the active branch.  If
>the conditional expression is not a constant, it couldn't be used as
>part of an #ifdef either.  #define is either a _parameter_, an inline
>function, or an inline procedure - the first is already in Fortran,
>the others are in the proposed 8x extensions.  Besides, as I've already
>pointed out, the functionality of #define can already be provided in a
>Fortran environment - portably (in fact, the RATFOR preprocessor has its
>source given in the original software tools document and includes a
>macro facility nearly identical to C macros - including ifdefs).
>

The point I was trying to make has to do with working around
differences in multiple environments.  Although for a single compiler
the ifdefs will produce  constants which can be compilerd out, the
constant will be different in different environments.  Consider this
bit of C code:

#ifdef CRAY2			/* Not all code is portable */

  {
    long t_addr;
    bcopy(from->h_addr, (caddr_t)&t_addr, from->h_length);
    to->sin_addr = (u_int) t_addr;
  }

#else

  bcopy(from->h_addr, (caddr_t) &to->sin_addr, from->h_length);

#endif CRAY2
 
CRI decided to implement a particular field in a particular structure
differently than the rest of the world.  On a Cray 2, the second
clause will not compile correctly, *not* because the compiler is
broken, but because something else is difficult to deal with.

Using the standard preprocess cpp, I have a predefine for each
compiler/OS environment, so I don't have to change my makefiles or
programs to get the correct code on a given machine.

There are a lot of examples of differences in libraries, operating
systems, etc, in which code like the above is useful.  This can be
overdone and make the code unreadable, but it can also be a major time
saver.

>Note: RATFOR isn't the best macro facility for Fortran. But it is an
>example of a completely portable public domain preprocessor for which
>the source is readily available to any interested programmer.

RATFOR is not completely portable.  It still doesn't run on the ETA-10
here, but people are working on it.  It has been a nontrivial exercise
to make it work on that machine, not do to anything wrong with the
ETA-10.

BTW, it is amusing that RATFOR was written as a workaround to
primitive Fortran control structures in an earlier Fortran, and it is
still around even with a cleaned up Fortran available. (;-)
+-+-+-+     I don't know who I am, why should you?     +-+-+-+
   |        fouts@lemming.nas.nasa.gov                    |
   |        ...!ames!orville!fouts                        |
   |        Never attribute to malice what can be         |
+-+-+-+     explained by incompetence.                 +-+-+-+