Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #3011
| From | Lydia Marie Williamson <lydiamariewilliamson@gmail.com> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Fortran to C/C++ translation: a running example. |
| Date | 2022-05-20 16:34 -0700 |
| Organization | Compilers Central |
| Message-ID | <22-05-038@comp.compilers> (permalink) |
| References | <22-05-032@comp.compilers> |
On Monday, May 16, 2022 at 2:53:09 PM UTC-5, Rock Brentwood wrote: > Another key issue the aliasing that goes on with "equivalence" constructs. > There is no good uniform translation for this into C ... it actually better > fits C++, where you have reference types available. There's really no good > reason why those have been left out of C, when other things which appeared > first in C++, like "const", "bool" or function prototypes, found their way > into C. > > However, a substantial chunk of use-cases for equivalence constructs can be > carved out as "enum" types, so there was a strength reduction step for this, > too. This is not exactly correct. It's "common blocks" that were handled in this way. In the Fortran source of Zork/dungeon, the "equivalence" statements and "common blocks" were used together, so it's easy to get the issue confused. I don't know if their being used together is something that always happened in Fortran, or if it was just particular to this program. > In the meanwhile, another project has already been staged for > conversion to C++ - LAPACK > > https://github.com/LydiaMarieWilliamson/lapack > > but is in a holding pattern for now. There were several stages to the translation, one of which involved regularizing and normalizing the Fortran, itself. This is also on the local machines here. But while that was happening, LAPACK came back alive, and is out on GitHub and being actively maintained again. Originally, it was (mostly) inert. > [It's been at least 20 years since I've done any sort of Fortran translation > so for this maze of twisty little passages, I'm afraid you're on your own. > I'm always surprised in translation exercises how many ways that languages > that look superficially the same are different in ways that make the translation much harder. -John] Things would be easier going into C++, instead of C, since it already has aliasing, operator overloading, re-defineable array indexing, and call-by-reference. This inclusion of more Fortran-friendly features into C++ was apparently done intentionally. [It was not unusual to use common and equivalence together, particularly when memory was tight. But equivalence is like a union, not an enum. -John]
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
Fortran to C/C++ translation: a running example. Rock Brentwood <rockbrentwood@gmail.com> - 2022-05-16 12:27 -0700
Re: Fortran to C/C++ translation: a running example. Thomas Koenig <tkoenig@netcologne.de> - 2022-05-17 14:59 +0000
Re: Fortran to C/C++ translation: a running example. Lydia Marie Williamson <lydiamariewilliamson@gmail.com> - 2022-05-20 16:34 -0700
Re: Fortran to C/C++ translation: a running example. gah4 <gah4@u.washington.edu> - 2022-05-21 09:31 -0700
Re: Fortran to C/C++ translation: a running example. Thomas Koenig <tkoenig@netcologne.de> - 2022-05-21 17:24 +0000
csiph-web