converting a 700,000+ line Fortran 77 plus 50,000+ line C++ program to C++, part 2

[Lynn McGuire]

We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++
lines of code engineering software product to C++. With all that code,
we produce four Win32 EXEs and three Win32 DLLs. My goal is to add four
Win64 EXEs and three Win64 DLLs to the product with the same
capabilities as the Win32 versions (console, windowed, Excel callable,
Excel embeddable). Plus support for Unicode named files and Unicode
file paths.

I am using a customized version of f2c at the moment to automate 80% of
the conversion from F77 to C++. I have added support for logical*8,
changed the output file from *.c to *.cpp, added an include for the
Fable fem.hpp template library, removed the trailing underscores from
the subroutine and common block names, removed the ftnlen arguments from
the character arguments, converted all F77 comments to the // instead of
the /* */, and a few other items. If desired, I am willing to post a
copy of my modified f2c on my website with the source code.
https://netlib.org/f2c/
https://en.wikipedia.org/wiki/F2c

f2c does not get me totally there. The Fortran character strings were
poorly handled so they will probably needed fixing for proper sizing and
alignment. The f2c i/o code is crap so I take the original F77 i/o code
and translate it by hand. The arrays in the argument list are still
based at an index of one so I convert those to base index of zero by
hand. All of the local and common block arrays were converted to a base
index of zero by f2c. I add the new *.cpp file to my Visual Studio
project. I then add the new function prototypes to my prototypes.h file
and I add any new common block structures to my commons.h file. I then
compile and fix until I get a clean compile.

I have converted over 29,000 lines of F77 code to C++ now. Almost a
hundred subroutines and several dozen common blocks. Most are compiling
cleanly in Visual C++ 2015. My testing is working well with the
problems being in the character string area. I am still aiming for
Christmas for completing the small data analysis program in my
calculation engine. It is somewhere around 150,000 lines of F77 code.
Tough to tell since it shares so much code with my big calculation
engine which is around 600,000 lines of F77 code and 50,000 lines of
C++. They share about 75,000 lines of F77 and C++ code.

Thanks,
Lynn

[JRR]

Am 19.11.22 um 07:01 schrieb Lynn McGuire:

>
> I have converted over 29,000 lines of F77 code to C++ now.  Almost a
> hundred subroutines and several dozen common blocks.  Most are compiling
> cleanly in Visual C++ 2015.  My testing is working well with the
> problems being in the character string area.  I am still aiming for
> Christmas for completing the small data analysis program in my
> calculation engine.  It is somewhere around 150,000 lines of F77 code.
> Tough to tell since it shares so much code with my big calculation
> engine which is around 600,000 lines of F77 code and 50,000 lines of
> C++.  They share about 75,000 lines of F77 and C++ code.
>
> Thanks,
> Lynn

From the experience in my field of physics, for all the codes that have
not been written from scratch, but translated from Fortran77 to C(++)
the main struggle started _after_ the codes had been translated. That is
because after the translation many codes are in state of pure C, not C++
code, and basically are not using any of the nice features of C++. Then
using things like OO, polymorphism and features of the C++ stdlib took
the authors much more time than the simple translation from Fortran77 to
C(++).


--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron
Hamburg, Germany
------------------------------------
invalid is desy .and. com is de

[Thomas Koenig]

JRR <juergen...@invalid.com> schrieb:

> Am 19.11.22 um 07:01 schrieb Lynn McGuire:
>>
>> I have converted over 29,000 lines of F77 code to C++ now.  Almost a
>> hundred subroutines and several dozen common blocks.  Most are compiling
>> cleanly in Visual C++ 2015.  My testing is working well with the
>> problems being in the character string area.  I am still aiming for
>> Christmas for completing the small data analysis program in my
>> calculation engine.  It is somewhere around 150,000 lines of F77 code.
>> Tough to tell since it shares so much code with my big calculation
>> engine which is around 600,000 lines of F77 code and 50,000 lines of
>> C++.  They share about 75,000 lines of F77 and C++ code.
>>
>> Thanks,
>> Lynn
>
> From the experience in my field of physics, for all the codes that have
> not been written from scratch, but translated from Fortran77 to C(++)
> the main struggle started _after_ the codes had been translated. That is
> because after the translation many codes are in state of pure C, not C++
> code, and basically are not using any of the nice features of C++. Then
> using things like OO, polymorphism and features of the C++ stdlib took
> the authors much more time than the simple translation from Fortran77 to
> C(++).

Which begs the question - why not introduce the OO featues that
modern Fortran can do, without first converting to the common
subset of C and C++?

[Öö Tiib]

That can be related to issue that if people who can and are eager
to refactor (or kind of hand-transpile) from decent C to decent C++
feel bit rare then people who can do same from F77 to modern
Fortran are nowhere to find.

[Lynn McGuire]

On 11/24/2022 7:28 AM, JRR wrote:
> Am 19.11.22 um 07:01 schrieb Lynn McGuire:
>>
>> I have converted over 29,000 lines of F77 code to C++ now.  Almost a
>> hundred subroutines and several dozen common blocks.  Most are
>> compiling cleanly in Visual C++ 2015.  My testing is working well with
>> the problems being in the character string area.  I am still aiming
>> for Christmas for completing the small data analysis program in my
>> calculation engine.  It is somewhere around 150,000 lines of F77 code.
>> Tough to tell since it shares so much code with my big calculation
>> engine which is around 600,000 lines of F77 code and 50,000 lines of
>> C++.  They share about 75,000 lines of F77 and C++ code.
>>
>> Thanks,
>> Lynn
>
> From the experience in my field of physics, for all the codes that have
> not been written from scratch, but translated from Fortran77 to C(++)
> the main struggle started _after_ the codes had been translated. That is
> because after the translation many codes are in state of pure C, not C++
> code, and basically are not using any of the nice features of C++. Then
> using things like OO, polymorphism and features of the C++ stdlib took
> the authors much more time than the simple translation from Fortran77 to
> C(++).

Interesting. Are there any public writeups to the experiences ?

I wonder if the problems were due to a lack of familiarity with C++ or
the fact that C++ has a much larger toolset than Fortran does.

Thanks,
Lynn

[Lynn McGuire]

The problem that I have run into in modern Fortran is that there is not
a good IDE (interactive development environment) on Windows. Since we
do not have any current customers on Unix / Linux, I do not know about
those platforms.

I tried Simply Fortran using GCC and GFortran and was very unsatisfied
with the debugger, we need to be able to stop at the 459th call to a
certain method. I tried Visual Studio 2019 with Intel Fortran and
Visual C++ and was very unhappy with the poor integration of Intel
Fortran into the IDE.

I like the modern features that C++ offers such as polymorphism but I am
very happy with the fact that C++ is a better compiler than C. I do
happen to use polymorphism in some of our common methods (pow, abs,
writing to an output file, etc) but it is a matter of convenience rather
than a goal of the project.

I will report next when I get my small data analysis tool running if
anyone is interested.

Thanks,
Lynn

[Gary Scott]

On 11/24/2022 11:38 PM, Lynn McGuire wrote:
>snip

>
> I tried Simply Fortran using GCC and GFortran and was very unsatisfied
> with the debugger, we need to be able to stop at the 459th call to a
> certain method.  I tried Visual Studio 2019 with Intel Fortran and
> Visual C++ and was very unhappy with the poor integration of Intel
> Fortran into the IDE.
>

VS on windows is the premier option. When the IVF integration works, it
is pretty good. What I've found though is that the integration breaks
frequently. In my case at present, it is broken and I can't seem to get
it repaired. The repair mechanism/upgrades think it is already
integrated when it isn't. So the help integration works, but the IDE
doesn't recognize the existing solutions (VS 2019) that worked a few
months ago. Very frustrating. I'll probably have to
uninstall/reinstall VS and then reinstall IVF in order to fix the
problem. It stopped working when VS installed one of it's own updates.

[Lynn McGuire]

Unfortunately, Microsoft does not care about Fortran. They showed that
many years ago when they dropped Powerstation. I do not know why Visual
Studio does not work with Intel Fortran more but it is disappointing.
We use Visual C++ 2015 to build our Windows user interface with 450,000
lines of C++ code. It works extremely well for us even though our code
dates back to Windows 1.0.

The only thing that I know to do at this time is to move my Fortran code
to a Microsoft supported language. After all, there is some evidence
floating about that Microsoft is getting ready to follow Apple, once
more, and jump to the ARM cpus and leave Intel behind.

Thanks,
Lynn

[Mut...@dastardlyhq.com]

On Fri, 25 Nov 2022 13:58:20 -0600
Lynn McGuire <lynnmc...@gmail.com> wrote:
>Unfortunately, Microsoft does not care about Fortran. They showed that
>many years ago when they dropped Powerstation. I do not know why Visual
>Studio does not work with Intel Fortran more but it is disappointing.
>We use Visual C++ 2015 to build our Windows user interface with 450,000
>lines of C++ code. It works extremely well for us even though our code

450K lines just for the interface?? How many windows does it have, a few
hundred??

>The only thing that I know to do at this time is to move my Fortran code
>to a Microsoft supported language. After all, there is some evidence
>floating about that Microsoft is getting ready to follow Apple, once
>more, and jump to the ARM cpus and leave Intel behind.

MS have tried that a number of times. Unless they can get the PC makers along
with them it'll be another failure. People who buy Apple don't have a choice
about the CPU, PC buyers do.

[Lynn McGuire]

On 11/26/2022 4:01 AM, Mut...@dastardlyhq.com wrote:
> On Fri, 25 Nov 2022 13:58:20 -0600
> Lynn McGuire <lynnmc...@gmail.com> wrote:
>> Unfortunately, Microsoft does not care about Fortran. They showed that
>> many years ago when they dropped Powerstation. I do not know why Visual
>> Studio does not work with Intel Fortran more but it is disappointing.
>> We use Visual C++ 2015 to build our Windows user interface with 450,000
>> lines of C++ code. It works extremely well for us even though our code
>
> 450K lines just for the interface?? How many windows does it have, a few
> hundred??

One main diagrammatic window with multiple sheets and about 150 dialogs
for the users to specify their simulation. The main window looks a lot
like Visio.
https://www.winsim.com/screenshots.html

Writing commercial software requires a lot of code.

>> The only thing that I know to do at this time is to move my Fortran code
>> to a Microsoft supported language. After all, there is some evidence
>> floating about that Microsoft is getting ready to follow Apple, once
>> more, and jump to the ARM cpus and leave Intel behind.
>
> MS have tried that a number of times. Unless they can get the PC makers along
> with them it'll be another failure. People who buy Apple don't have a choice
> about the CPU, PC buyers do.

This is true. But the lower energy requirements of the ARM chips makes
them very interesting, especially for laptops. Plus, several USA states
)California, etc) are starting to regulate cpu power levels, these will
probably drop as time goes on.

Lynn

[JRR]

Am 25.11.22 um 06:06 schrieb Lynn McGuire:

> On 11/24/2022 7:28 AM, JRR wrote:
>> Am 19.11.22 um 07:01 schrieb Lynn McGuire:
>>>

>

> Interesting.  Are there any public writeups to the experiences ?
>
> I wonder if the problems were due to a lack of familiarity with C++ or
> the fact that C++ has a much larger toolset than Fortran does.
>
> Thanks,
> Lynn
>

There was a data format, called StdHEP, in high energy physics that is
still in use in legacy applications (for data sets of experiments that
have been run in the 1990s e.g.). This uses common blocks for the data
structures, and a lot of F77 code, interfaced with C TIRPC libraries.
This has been converted and partially rewritten under a new name, HepMC,
in 2001. It was a very basic new implementation, more C, than C++, and
less efficient than the old implementation. It took them 16 years until
2017 to come with a modern C++ version of this data format.

[Lynn McGuire]

On 11/26/2022 2:38 PM, JRR wrote:
> Am 25.11.22 um 06:06 schrieb Lynn McGuire:
>> On 11/24/2022 7:28 AM, JRR wrote:
>>> Am 19.11.22 um 07:01 schrieb Lynn McGuire:
>>>>
>
>>
>> Interesting.  Are there any public writeups to the experiences ?
>>
>> I wonder if the problems were due to a lack of familiarity with C++ or
>> the fact that C++ has a much larger toolset than Fortran does.
>>
>> Thanks,
>> Lynn
>>
>
> There was a data format, called StdHEP, in high energy physics that is
> still in use in legacy applications (for data sets of experiments that
> have been run in the 1990s e.g.). This uses common blocks for the data
> structures, and a lot of F77 code, interfaced with C TIRPC libraries.
> This has been converted and partially rewritten under a new name, HepMC,
> in 2001. It was a very basic new implementation, more C, than C++, and
> less efficient than the old implementation. It took them 16 years until
> 2017 to come with a modern C++ version of this data format.

I will let you know how "efficient" my translation is when I am
complete. I can assure you that is definitely one of my concerns. I
time our software regularly to see what our changes have done to it.

Thanks,
Lynn

[Gary Scott]

On 11/26/2022 1:33 PM, Lynn McGuire wrote:
> On 11/26/2022 4:01 AM, Mut...@dastardlyhq.com wrote:
>> On Fri, 25 Nov 2022 13:58:20 -0600
>> Lynn McGuire <lynnmc...@gmail.com> wrote:
>>> Unfortunately, Microsoft does not care about Fortran.  They showed that
>>> many years ago when they dropped Powerstation.  I do not know why Visual
>>> Studio does not work with Intel Fortran more but it is disappointing.
>>> We use Visual C++ 2015 to build our Windows user interface with 450,000
>>> lines of C++ code.  It works extremely well for us even though our code
>>
>> 450K lines just for the interface?? How many windows does it have, a few
>> hundred??
>
> One main diagrammatic window with multiple sheets and about 150 dialogs
> for the users to specify their simulation.  The main window looks a lot
> like Visio.
>    https://www.winsim.com/screenshots.html
>

These would have been super easy with GINO. It was designed exactly for
this type of application. A GUI API tailored specifically for Fortran.

[Lynn McGuire]

We had a Gino CAD user interface on the Vax back in the 1980s. It was
not easy to write nor was it easy to maintain. The plotter/printer
interface was absolutely horrible, you essentially had to rewrite the
driver for each plotter or printer model.

Lynn

[Thomas Koenig]

Lynn McGuire <lynnmc...@gmail.com> schrieb:

> On 11/26/2022 4:01 AM, Mut...@dastardlyhq.com wrote:
>> On Fri, 25 Nov 2022 13:58:20 -0600
>> Lynn McGuire <lynnmc...@gmail.com> wrote:
>>> Unfortunately, Microsoft does not care about Fortran. They showed that
>>> many years ago when they dropped Powerstation. I do not know why Visual
>>> Studio does not work with Intel Fortran more but it is disappointing.
>>> We use Visual C++ 2015 to build our Windows user interface with 450,000
>>> lines of C++ code. It works extremely well for us even though our code
>>
>> 450K lines just for the interface?? How many windows does it have, a few
>> hundred??
>
> One main diagrammatic window with multiple sheets and about 150 dialogs
> for the users to specify their simulation. The main window looks a lot
> like Visio.
> https://www.winsim.com/screenshots.html
>
> Writing commercial software requires a lot of code.

This is probably a few decades too late for the interface code, but
have you looked at GTK and its Fortran binding, fortran-gtk?

[Scott Lurndal]

I would expect that 40 years of updates would have fixed
the problems you note below.

http://gino.co.uk/

[Gary Scott]

Its come a long way in 32 years. I've (combined with my employer) paid
them about $50k to upgrade it in many areas. It started out as output
only, similar to mainframe GDDM. But it now has full interactive
graphics editing ability (including segments and transformations and
attribute modifications for pre-drawn segments). Pretty much full CAD
capability and is integrated with openGL if you choose that driver.
It supports 2D and 3D but I've not had the need for 3D other than
playing so I've not worked through that area of support.

> Lynn
>

[Gary Scott]

I'll also note that they're really nice people and will fix anything you
need fixed. I've found them extremely responsive. Sometimes though a
problem may be hard to reproduce so providing an example helps a lot. A
problem is that it is a pretty huge code base for the size of the
development/support team, but I've had numerous examples of overnight
updates over the years.
>
>> Lynn
>>
>

[Lynn McGuire]

No, that is not the problem.

Thanks,
Lynn

[Mut...@dastardlyhq.com]

On Sat, 26 Nov 2022 13:33:46 -0600

Lynn McGuire <lynnmc...@gmail.com> wrote:
>On 11/26/2022 4:01 AM, Mut...@dastardlyhq.com wrote:
>> On Fri, 25 Nov 2022 13:58:20 -0600
>> Lynn McGuire <lynnmc...@gmail.com> wrote:
>>> Unfortunately, Microsoft does not care about Fortran. They showed that
>>> many years ago when they dropped Powerstation. I do not know why Visual
>>> Studio does not work with Intel Fortran more but it is disappointing.
>>> We use Visual C++ 2015 to build our Windows user interface with 450,000
>>> lines of C++ code. It works extremely well for us even though our code
>>
>> 450K lines just for the interface?? How many windows does it have, a few
>> hundred??
>
>One main diagrammatic window with multiple sheets and about 150 dialogs
>for the users to specify their simulation. The main window looks a lot
>like Visio.
> https://www.winsim.com/screenshots.html

Looks like it was designed in the 90s. I still fail to see how even with
what you've mentioned it can possibly require 450K lines of C++.

>Writing commercial software requires a lot of code.

Not that much for just the interface alone. One commercial windows package
I worked on which was heavily mathematical and had complex graphics in numerous
sub windows was "only" 100K lines.

[Lynn McGuire]

We abandoned our Gino front end on Vax VMS in 1993 and moved totally to
Windows. We could not support both.

Lynn

[Gary Scott]

GINO has been primarily a windows product since the 80s. Other OS are a
subset in terms of GUI support.

> Lynn
>
>

[Gary Scott]

er...90s.

>> Lynn
>>
>>
>