fortran to C converter

[Henry Spencer]

In article <12000 at lanl.gov> jlg at lanl.gov (Jim Giles) writes:
>... 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?  ...

Um, it may not have come to your attention that C++ will do conversions
for you (given definition of suitable conversion operators).  See pages
173-177 in Stroustrup's book; you have in fact hit on *precisely* the
example he uses to explain why automatic application of user-defined
conversions is a good thing.  If that is not satisfactory, i.e. if you
really do want all those operations to be different, you will of course
need to specify them all no matter what you do.

>      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.

Given in-header definitions of the operators, there is no reason why a
C++ optimizing compiler can't do this.  Existing C++ compilers, by and
large, are not heavy optimizers; the language is too young for that yet.
They will come.
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry at zoo.toronto.edu