Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran vs C for computations
Message-ID: <3338@lanl.gov>
Date: 8 Sep 88 19:37:32 GMT
References: <3169@emory.uucp>
Organization: Los Alamos National Laboratory
Lines: 37

From article <3169@emory.uucp>, by platt@emory.uucp (Dan Platt):
> I object to this argument.  There are some functions provided in certain
> environments that are not provided in other environments (specifically,
> functions that deal with dates, times, extended function sets such as error
> functions or Bessel functions) or which exist but have different forms on
> each system. [...

So what?  Functions called by dead code aren't really called after all.
What difference does it make if the _if_ statement or the _ifdef_ directive
is the visable syntax?  The _ifdef_ was only introduced because many 
compilers are _very_ bad at dead code elimination.

> ...]         The biggest problem concerns 'open' statements which seem
> to be very system specific; I don't believe that an IF with a constant
> expression would let that by, even if the final code generation included the
> non-compatible code. [...]

_OPEN_ statements which are 'system specific' are non-standard and don't
enter into this discussion.  In any case, a compiler which complains of
syntax errors in an OPEN statement which appears in the middle of a dead
code sequence should be fixed.  Furthermore, there are ways to provide
I/O extensions to Fortran without muching up the OPEN statement (I am just
finishing an I/O support library for Fortran on the Crays, I provide a
large number of extensions - including all the features proposed in
8x - without altering the OPEN statement syntax in any compiler-checkable
way).  

> [...]                  A pre-processed #ifdef would clean up that problem.

Then use a preprocessed #ifdef with your fortran code if your vendor
has supplied you with a drain-damaged compiler.  This gets back to my
original point - C does _not_ have a monopoly on preprocessors!  I've
preprocessed Fortran codes for years and never had a portability
problem arise because of it (in fact, preprocessing helps eliminate
such problems - as you have pointed out yourself).

J. Giles
Los Alamos