fortran to C converter

[Jim Giles]

>From article <1989Apr13.173331.2116 at utzoo.uucp>, by henry at utzoo.uucp (Henry Spencer):
> In article <11926 at lanl.gov> jlg at lanl.gov (Jim Giles) writes:
>> [...]
>>      COMPLEX A,B,C
>>      ...
>>      A=B*C
>>
>>... I've not heard that inlining is available on
>>any C++ presently marketed.
> 
> In any sensible implementation of "complex" in any sensible C++ compiler,
         ^^^^^^^^
> that code will get inlined, because the declarations of the = and *
> operators (in a .h file, usually) will contain the definitions and the
> compiler will therefore inline them.  No procedure calls needed.

I guess that makes the implementations I've seen in C++ documents
not 'sensible'.  In any case, the mechanism you describe (and any C++
mechanism) would require 7 different definitions for each operator:
COMPLEX*INT, COMPLEX*FLOAT, COMPLEX*DOUBLE, COMPLEX*COMPLEX, INT*COMPLEX,
FLOAT*COMPLEX, DOUBLE*COMPLEX.  Or did you think that an implementation
that _didn't_ support mixed mode operations was satisfactory?  (This is,
in fact, one of the problems with object oriented languages - they don't
handle mixed mode operations very well.  I recently added COMPLEX to a
SmallTalk implementation.  In order to do so, I had to modify the definitions
of ALL the operators of ALL the other numeric data types so they would
recognize when their other operand was COMPLEX.)

By the way, mixed mode operations are a _very_ object oriented thing to
want to do.  COMPLEX is a subclass of NUMBER, just like FLOAT, INT,
FRACTION, etc..  The primitive operators +, -, *, and / are defined on
class NUMBER (even though separately implemented by each subclass).
Therefore, all mixed mode operations should be expected to work.

-----------------------------------------------------------------------

Consider the example again:
      COMPLEX A,B,C
      REAL X
      ...
      B=X
      A=B*C

All the Fortrans I've ever used would recognize an optimization that
I've not seen _any_ C++ compiler recognize:  The multiply need only
do 2 FLOAT multiplies, not 4 multiplies and 2 adds.  The C++ code will
blindly follow the definition of the operator (COMPLEX*COMPLEX) and
will not notice that the imaginary part of B is guaranteed to be zero.
Even if you solve the 'inlining' problem I mentioned in my last article,
these problems of mixed mode and optimization make the C++ implementation
less desireable.