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 60% to
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 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 8,000 lines of F77 code to C++ now. Several dozen subroutines and several dozen common blocks. Most are compiling cleanly
in Visual C++ 2015. My limited testing is working well and I will
expand my testing when I hit 15,000 or 20,000 lines of F77 code
converted. I hoping to get a complete build of the smaller of the Win32
DLLs by the end of the year and a full build by next June. One of my programmers thinks that we will be lucky to get a complete build by late 2024.
Lynn
On Sunday, October 23, 2022 at 3:16:48 PM UTC-7, Lynn McGuire wrote:(snip)
We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++ lines of code engineering software product to C++.
I'm not trying to be a smart ass or a troll and I'm not trying to change your mind.
I'm wondering why you want to convert all of the F77 to C++ rather than to modern Fortran that can call or be called from the existing C++ routines.
As a side note, I used to work for a group at Oak Ridge National Laboratory (ORNL) that developed the SCALE code system that is used for nuclear analysis.
A lot of effort was spent many years ago converting it from F77 to Fortran 9x.
Now, after addition of a number of computer science trained staff to that group
over the years from the late 1990s to the present, everything is slowly being converted to C++. A number of the SCALE codes are being changed to run on massively parallel machines, but there are libraries for both Fortran and C++ available for such machines. I have my suspicions why they are converting but that is irrelevant here.
Is there a reason such as availability of certain libraries or code efficiency that
you want to convert all your F77 code to C++?
The reason I am interested is that I have some old F77 code that ran on IBM mainframes, Unix workstations, and DOS PCs which I want to document and revive to run on Windows and Linux now that I am retired and have the time.
I had a C/C++ class in the late 1990s but never used any of it at work. I am taking some online self study classes in C/C++ so that I can at least read a little of existing codes and use it in my project if I find it useful.
We used three features in our F66 / F77 code which are turning out to be problematic in porting to a new Fortran compiler that supports 64 bit software. The first is the carriage control option in printing to
stdout or a file. This was never a Fortran standard feature but
everyone used it back in the 1960s, 1970s, and 1980s.
This killed our
port to gfortran several years ago but it is now supported there
reputedly. We are ripping it out of our formats as a part of our
conversion to C++.
Almost all of the Fortran compilers are now free. This is a bad sign, especially since Intel Fortran, the premier Fortran compiler, just
jumped to free. To me, this says that future of Fortran is cloudy at best.
Nothing in this world is perfect but moving to a single programming
language should help us in the long run. Our software is embeddable in
Excel or can embed Excel in itself, all my glue code is in C++ which
really points the direction to me.
On 10/26/2022 7:59 PM, gah4 wrote:.
.I think if I was in the mood for doing it, it would be Java and not C++, but then that is just me.
Would you really write a 750,000 line calculation engine in Java ?.
On Wednesday, October 26, 2022 at 1:56:09 PM UTC-7, Lynn McGuire wrote:.
(snip)
We used three features in our F66 / F77 code which are turning out to be problematic in porting to a new Fortran compiler that supports 64 bit software. The first is the carriage control option in printing to
stdout or a file. This was never a Fortran standard feature but
everyone used it back in the 1960s, 1970s, and 1980s.
It is in the Fortran 66 standard with "when formatted records are.
prepared for printing". For one, you could argue that not all are
being prepared for printing, at least not in the Fortran 66 sense.
For IBM OS/360 and successors, it is not part of Fortran but of
the OS. If the DCB has RECFM=FBA you get them, if FB you don't.
But the is reminding me of a Fortran to C port in about 1987.
The C code had a tendency to write the '\n' at the beginning
of a printf() call, instead of at the end. Sometime later, those
all got fixed, but it was related to the way that Fortran I/O
always starts on a new line, and C doesn't do that.
.This killed our
port to gfortran several years ago
but it is now supported there.
reputedly. We are ripping it out of our formats as a part of our
conversion to C++.
Well, the C/Unix tradition was to write '\f' (form feed characters).
to the file. I always thought that seemed less standardized
than ASA characters. Also, there is a Unix program to convert
from ASA characters.
In any case, yes, I always found ASA control characters funny
when using interactive terminals for output devices. They are
fine for line printers, though.
Almost all of the Fortran compilers are now free. This is a bad sign, especially since Intel Fortran, the premier Fortran compiler, just
jumped to free. To me, this says that future of Fortran is cloudy at best.
Seems to me like web browsers are now always free. Pay ones can't.
compete with free ones.
Nothing in this world is perfect but moving to a single programming language should help us in the long run. Our software is embeddable in Excel or can embed Excel in itself, all my glue code is in C++ which
really points the direction to me.
We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++
lines of code engineering software product to C++.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
We used three features in our F66 / F77 code which are turning out to be
problematic in porting to a new Fortran compiler that supports 64 bit
software. The first is the carriage control option in printing to
stdout or a file. This was never a Fortran standard feature but
everyone used it back in the 1960s, 1970s, and 1980s. This killed our
port to gfortran several years ago but it is now supported there
reputedly.
I am not sure how compiler support of ASA carriage control
by a compiler is supposed to look like (apart from the
mandated leading space in free-form output).
The traditional UNIX way is to pipe it through asa(1), which
emulates the traditional carriage control with overstrike
characters etc. This is reasonably easy to write, I once
wrote such a utility myself (and lost the source) but Debian
has it. Source at https://sources.debian.org/src/asa/1.2-1.1/ .
We are ripping it out of our formats as a part of our
conversion to C++.
Good riddance.
We use zero initialization of all global and local variables. This
killed our first port to Intel Fortran in 2005 ??? when it uncovered a
linker bug / crash. We have removed the need for this from a portion of
our Fortran code but will be a problem in the C++ conversion.
That is a bigger problem.
Not sure if your code runs under Linux. If it does, you might want
to run it under valgrind, which will generate tons of errors if
undefined variables are used.
We use Fortran structures, popularized by DEC back in the 1970s and
1980s, but they never became part of the Fortran standard. We are
converting our structure code to integer*8 and logical*8 as a part of
the C++ port.
Huh?
Almost all of the Fortran compilers are now free. This is a bad sign,
especially since Intel Fortran, the premier Fortran compiler, just
jumped to free. To me, this says that future of Fortran is cloudy at best.
Why should this be a bad thing? Intel uses the compiler to sell chips,
and so does IBM for POWER.
Nothing in this world is perfect but moving to a single programming
language should help us in the long run. Our software is embeddable in
Excel or can embed Excel in itself, all my glue code is in C++ which
really points the direction to me.
In the immortal words of a J3 member...
" Hiring someone else to write your C++ code is probably a good
idea for preserving sanity. Although having to read the code
later will undo any of the previously mentioned benefits."
Almost all of the Fortran compilers are now free. This is a bad sign, especially since Intel Fortran, the premier Fortran compiler, just
jumped to free. To me, this says that future of Fortran is cloudy at best.
I am not sure how compiler support of ASA carriage control
by a compiler is supposed to look like (apart from the
mandated leading space in free-form output).
On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote:
On 10/26/2022 7:59 PM, gah4 wrote:.
.I think if I was in the mood for doing it, it would be Java and not C++, >>> but then that is just me.
Would you really write a 750,000 line calculation engine in Java ?.
I think the question that you should be asking yourself is
"would you really write a 750,000 line calculation engine in C++ ?"
On 10/27/2022 2:56 AM, Robin Vowels wrote:
On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote:
On 10/26/2022 7:59 PM, gah4 wrote:.
.I think if I was in the mood for doing it, it would be Java and not C++, >>>> but then that is just me.
Would you really write a 750,000 line calculation engine in Java ?.
I think the question that you should be asking yourself is
"would you really write a 750,000 line calculation engine in C++ ?"
Since I am doing that, yes, in a heartbeat.
BTW, this is actually the third software program that I have converted
to C or C++. This is the biggest by far. My first was:
https://www.winsim.com/steam/steam.html
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 10/27/2022 2:56 AM, Robin Vowels wrote:
On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote: >>>> On 10/26/2022 7:59 PM, gah4 wrote:
.
.I think if I was in the mood for doing it, it would be Java and not C++, >>>>> but then that is just me.
Would you really write a 750,000 line calculation engine in Java ?.
I think the question that you should be asking yourself is
"would you really write a 750,000 line calculation engine in C++ ?"
Since I am doing that, yes, in a heartbeat.
BTW, this is actually the third software program that I have converted
to C or C++. This is the biggest by far. My first was:
https://www.winsim.com/steam/steam.html
That looks nice, steam properties are something that you sometimes
need...
One of the first applied programs I ever wrote was the simulation
for a steam turbine. For his job, my father had a MS-DOS program
which calculated steam properties (you could add the usual values,
and it would calculate the rest). Via a MS-DOS batch file, I
then wrote a program to calculate steam turbine expansion if an
isentropic efficiency was given.
Another story along these lines... quite some years ago, we
were sitting in a conference room, and the question came up what
temperature corresponded to a certain steam pressure in one of
our plants. A colleague from Thailand then took a steam table
out of his shirt pocket and supplied the answer. Never leave
home without it :-)
On 10/29/2022 9:08 AM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 10/27/2022 2:56 AM, Robin Vowels wrote:
On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote: >>>>> On 10/26/2022 7:59 PM, gah4 wrote:
.
.I think if I was in the mood for doing it, it would be Java and
not C++,
but then that is just me.
Would you really write a 750,000 line calculation engine in Java ?.
I think the question that you should be asking yourself is
"would you really write a 750,000 line calculation engine in C++ ?"
Since I am doing that, yes, in a heartbeat.
BTW, this is actually the third software program that I have converted
to C or C++. This is the biggest by far. My first was:
https://www.winsim.com/steam/steam.html
That looks nice, steam properties are something that you sometimes
need...
One of the first applied programs I ever wrote was the simulation
for a steam turbine. For his job, my father had a MS-DOS program
which calculated steam properties (you could add the usual values,
and it would calculate the rest). Via a MS-DOS batch file, I
then wrote a program to calculate steam turbine expansion if an
isentropic efficiency was given.
Another story along these lines... quite some years ago, we
were sitting in a conference room, and the question came up what
temperature corresponded to a certain steam pressure in one of
our plants. A colleague from Thailand then took a steam table
out of his shirt pocket and supplied the answer. Never leave
home without it :-)
Yup, the old Combustion Engineering Steam Table pamphlets. A CE boiler
guy would stop by and hand them out like candy. I have 2 or 3 of them still. They are the 1967 ASME steam table which my software is. I have
a program that calculates steam turbine efficiency called Isencalc
available on that page. Someday I am going to convert it from DOS to
Win32.
https://www.amazon.com/Steam-Tables-Properties-Saturated-Superheated/dp/B003O5S3ZW/
My process simulation software has the 1991 Steam Tables in it along
with 60 other equations of state.
https://www.winsim.com/index.html
Lynn
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
We used three features in our F66 / F77 code which are turning out to be
problematic in porting to a new Fortran compiler that supports 64 bit
software. The first is the carriage control option in printing to
stdout or a file. This was never a Fortran standard feature but
everyone used it back in the 1960s, 1970s, and 1980s. This killed our
port to gfortran several years ago but it is now supported there
reputedly.
I am not sure how compiler support of ASA carriage control
by a compiler is supposed to look like (apart from the
mandated leading space in free-form output).
The traditional UNIX way is to pipe it through asa(1), which
emulates the traditional carriage control with overstrike
characters etc. This is reasonably easy to write, I once
wrote such a utility myself (and lost the source) but Debian
has it. Source at https://sources.debian.org/src/asa/1.2-1.1/ .
We are ripping it out of our formats as a part of our
conversion to C++.
Good riddance.
We use zero initialization of all global and local variables. This
killed our first port to Intel Fortran in 2005 ??? when it uncovered a
linker bug / crash. We have removed the need for this from a portion of
our Fortran code but will be a problem in the C++ conversion.
That is a bigger problem.
Not sure if your code runs under Linux. If it does, you might want
to run it under valgrind, which will generate tons of errors if
undefined variables are used.
We use Fortran structures, popularized by DEC back in the 1970s and
1980s, but they never became part of the Fortran standard. We are
converting our structure code to integer*8 and logical*8 as a part of
the C++ port.
Huh?
Almost all of the Fortran compilers are now free. This is a bad sign,
especially since Intel Fortran, the premier Fortran compiler, just
jumped to free. To me, this says that future of Fortran is cloudy at best.
Why should this be a bad thing? Intel uses the compiler to sell chips,
and so does IBM for POWER.
Nothing in this world is perfect but moving to a single programming
language should help us in the long run. Our software is embeddable in
Excel or can embed Excel in itself, all my glue code is in C++ which
really points the direction to me.
In the immortal words of a J3 member...
" Hiring someone else to write your C++ code is probably a good
idea for preserving sanity. Although having to read the code
later will undo any of the previously mentioned benefits."
On 10/29/2022 1:59 PM, Lynn McGuire wrote:
On 10/29/2022 9:08 AM, Thomas Koenig wrote:CO2 is the wave of the future, any adaptations?
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 10/27/2022 2:56 AM, Robin Vowels wrote:
On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire
wrote:
On 10/26/2022 7:59 PM, gah4 wrote:.
.I think if I was in the mood for doing it, it would be Java and
not C++,
but then that is just me.
Would you really write a 750,000 line calculation engine in Java ?.
I think the question that you should be asking yourself is
"would you really write a 750,000 line calculation engine in C++ ?"
Since I am doing that, yes, in a heartbeat.
BTW, this is actually the third software program that I have converted >>>> to C or C++. This is the biggest by far. My first was:
https://www.winsim.com/steam/steam.html
That looks nice, steam properties are something that you sometimes
need...
One of the first applied programs I ever wrote was the simulation
for a steam turbine. For his job, my father had a MS-DOS program
which calculated steam properties (you could add the usual values,
and it would calculate the rest). Via a MS-DOS batch file, I
then wrote a program to calculate steam turbine expansion if an
isentropic efficiency was given.
Another story along these lines... quite some years ago, we
were sitting in a conference room, and the question came up what
temperature corresponded to a certain steam pressure in one of
our plants. A colleague from Thailand then took a steam table
out of his shirt pocket and supplied the answer. Never leave
home without it :-)
Yup, the old Combustion Engineering Steam Table pamphlets. A CE
boiler guy would stop by and hand them out like candy. I have 2 or 3
of them still. They are the 1967 ASME steam table which my software
is. I have a program that calculates steam turbine efficiency called
Isencalc available on that page. Someday I am going to convert it
from DOS to Win32.
https://www.amazon.com/Steam-Tables-Properties-Saturated-Superheated/dp/B003O5S3ZW/
My process simulation software has the 1991 Steam Tables in it along
with 60 other equations of state.
https://www.winsim.com/index.html
Lynn
We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++Thank you for sharing your experience on that tough work. For years I had also paid lots of effort to convert all F77 codes to modern Fortran and I stopped that job because I found its nonsense. Is that how we are removing Fortran from its world?
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
On Saturday, November 19, 2022 at 1:01:25 PM UTC+7, Lynn McGuire wrote:
We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++Thank you for sharing your experience on that tough work. For years I had also paid lots of effort to convert all F77 codes to modern Fortran and I stopped that job because I found its nonsense. Is that how we are removing Fortran from its world?
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
..
Thank you for sharing your experience on that tough work. For years I had also paid lots of effort to convert all F77 codes to modern Fortran and I stopped that job because I found its nonsense. Is that how we are removing Fortran from its world?
..
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++?
..
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(++). ..
..
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 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.
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.
On Wednesday, November 23, 2022 at 6:36:28 PM UTC-5, vie...@gmail.com wrote:
..
Thank you for sharing your experience on that tough work. For years I had also paid lots of effort to convert all F77 codes to modern Fortran and I stopped that job because I found its nonsense. Is that how we are removing Fortran from its world?
@vie...@gmail.com,energy applied to simulate the chemical processes are not applicable at steady-state). The simulator may have dynamic modes where the PDEs and the ODEs in terms of time become relevant. Anyways, what is stake is heavy-duty number-crunching using arrays
Can you please elaborate on "I stopped that job because I found its nonsense"?
Our experience suggests what OP's pursuit - "converting a 700,000+ line Fortran 77 plus 50,000+ line C++ program to C++" - to be UTTER NONSENSE.
Please note OP is the President and CEO of a commercial software company, WinSim Inc. https://www.winsim.com/staff.html
And the software in question is primarily the *calculation engine* in the area of chemical process simulation in steady-state conditions (d/dt - where t is time - terms in the physical relations starting with the laws of conservation of mass and then
..You have zero credibility in
my opinion when you start up personal attacks like this. What are you, 15 ?
..
No thanks to your advice,
You've been on this forum and comp.lang.c++, etc. for ages stating you are going to refactor your XXXK lines of "F77" code to something else, usually C++. You are still trying. In the mean time, you have made many posts about "zero initialization" inyour "F77" code and what-not, none of which make any sense whatsoever that they should persist so long.
...
Why are you continuing as the President and CEO if you can't accept advice and delegate tasks that should be delegated to those who can do a far better job at it than you? Look up your job description, that will be first on the list.
...
On Monday, November 28, 2022 at 7:04:16 PM UTC-5, FortranFan wrote:your "F77" code and what-not, none of which make any sense whatsoever that they should persist so long.
You've been on this forum and comp.lang.c++, etc. for ages stating you are going to refactor your XXXK lines of "F77" code to something else, usually C++. You are still trying. In the mean time, you have made many posts about "zero initialization" in
meet his needs. I am probably with most of the folks here in thinking that converting this code to C++ is a questionable choice for this company, but the "process" they have chosen is beyond absurd. Trying to get through to some people is not worth the...
Why are you continuing as the President and CEO if you can't accept advice and delegate tasks that should be delegated to those who can do a far better job at it than you? Look up your job description, that will be first on the list.
...
A number of years ago I explained our system for Fortran-to-C++ conversion to this person that would have provided them with clear, validated C++ (instead of the mess that F2C produces) and got a lot of (to me nonsensical) "reasons" why that wouldn't
Are you the guy who wanted $75,000 up front plus 5% of my future sales
in perpetuity ?
On 11/28/2022 8:05 PM, Objexx Engineering wrote:in your "F77" code and what-not, none of which make any sense whatsoever that they should persist so long.
On Monday, November 28, 2022 at 7:04:16 PM UTC-5, FortranFan wrote:
You've been on this forum and comp.lang.c++, etc. for ages stating you are going to refactor your XXXK lines of "F77" code to something else, usually C++. You are still trying. In the mean time, you have made many posts about "zero initialization"
meet his needs. I am probably with most of the folks here in thinking that converting this code to C++ is a questionable choice for this company, but the "process" they have chosen is beyond absurd. Trying to get through to some people is not worth the...
Why are you continuing as the President and CEO if you can't accept advice and delegate tasks that should be delegated to those who can do a far better job at it than you? Look up your job description, that will be first on the list.
...
A number of years ago I explained our system for Fortran-to-C++ conversion to this person that would have provided them with clear, validated C++ (instead of the mess that F2C produces) and got a lot of (to me nonsensical) "reasons" why that wouldn't
Are you the guy who wanted $75,000 up front plus 5% of my future sales
in perpetuity ?
Lynn
On Monday, November 28, 2022 at 7:04:16 PM UTC-5, FortranFan wrote:your "F77" code and what-not, none of which make any sense whatsoever that they should persist so long.
You've been on this forum and comp.lang.c++, etc. for ages stating you are going to refactor your XXXK lines of "F77" code to something else, usually C++. You are still trying. In the mean time, you have made many posts about "zero initialization" in
...
Why are you continuing as the President and CEO if you can't accept advice and delegate tasks that should be delegated to those who can do a far better job at it than you? Look up your job description, that will be first on the list.
...
A number of years ago I explained our system for Fortran-to-C++
conversion to this person that would have provided them with clear,
validated C++ (instead of the mess that F2C produces) and got a lot
of (to me nonsensical) "reasons" why that wouldn't meet his needs.
I have provided facts about the futility of trying to help with this "project" so that the great forum members who offer their expertise can move on. I consider that a service to the community. If you choose to keep trying to help them and expect toget through, well, that's on you. This is nobody's potential customer, just a time and energy vampire. But if you enjoy frustration, keep at it!
software such as WinSim are still likely to be on higher-end laptops i.e., Intel CPUs for the foreseeable future.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.
Are not the higher-end Apple macOS laptops still using Intel CPUs, as opposed to ARM? In an Enterprise domain like at the influential customers of WinSim Inc., the users - mostly process/chemical/petroleum/mechanical engineers, etc. - who have to run
On 11/29/2022 1:28 AM, Objexx Engineering wrote:get through, well, that's on you. This is nobody's potential customer, just a time and energy vampire. But if you enjoy frustration, keep at it!
I have provided facts about the futility of trying to help with this "project" so that the great forum members who offer their expertise can move on. I consider that a service to the community. If you choose to keep trying to help them and expect to
I am sorry that you disagree with me about my methods of getting things done. I would urge you to killfile me.
I guess about 10 or so years ago I talked to 4 or 5 vendors of F77 to C
/ C++ translation tools. I ended up buying Cobalt Blue's FOR_C tool for $4,000 and thought that I had tested it fairly well. When I started the translation project about six months or a year later (I live in the
tyranny of the now), I got burned in that it did not handle Fortran data structures which are extensively used in my F77 source code.
In the
meantime, the guy closed his business down. I offered to add the
support myself if he would forward the source code to me but he would
not. So here I am down the road, rolling my own solution since I have serious trust issues now and very non standard F77 / F66 code.
On Wednesday, November 30, 2022 at 6:26:32 AM UTC+11, Lynn McGuire wrote:get through, well, that's on you. This is nobody's potential customer, just a time and energy vampire. But if you enjoy frustration, keep at it!
On 11/29/2022 1:28 AM, Objexx Engineering wrote:
I have provided facts about the futility of trying to help with this "project" so that the great forum members who offer their expertise can move on. I consider that a service to the community. If you choose to keep trying to help them and expect to
I am sorry that you disagree with me about my methods of getting things
done. I would urge you to killfile me.
I guess about 10 or so years ago I talked to 4 or 5 vendors of F77 to C
/ C++ translation tools. I ended up buying Cobalt Blue's FOR_C tool for
$4,000 and thought that I had tested it fairly well. When I started the
translation project about six months or a year later (I live in the
tyranny of the now), I got burned in that it did not handle Fortran data
structures which are extensively used in my F77 source code.
F77 didn't have data strctures. That was your mistake. You didn't
really have F77 source.
In the
meantime, the guy closed his business down. I offered to add the
support myself if he would forward the source code to me but he would
not. So here I am down the road, rolling my own solution since I have
serious trust issues now and very non standard F77 / F66 code.
I am converting all of my integers and logicals to integer*8 as we store
C pointers in them so that is getting us ready for the Win64 port.
On 11/30/2022 4:10 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I am converting all of my integers and logicals to integer*8 as we store >>> C pointers in them so that is getting us ready for the Win64 port.
That sounds very dangerous. This violates the C standard, and
another revision of the optimizers might just break your code.
Can you educate me a little bit more please ? How does this violate the
C standard ? The C pointers are currently returned from calls to malloc
and realloc.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I am converting all of my integers and logicals to integer*8 as we store
C pointers in them so that is getting us ready for the Win64 port.
That sounds very dangerous. This violates the C standard, and
another revision of the optimizers might just break your code.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 11/30/2022 4:10 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I am converting all of my integers and logicals to integer*8 as we store >>>> C pointers in them so that is getting us ready for the Win64 port.
That sounds very dangerous. This violates the C standard, and
another revision of the optimizers might just break your code.
Can you educate me a little bit more please ? How does this violate the
C standard ? The C pointers are currently returned from calls to malloc
and realloc.
Hm, I think I oversimplified.
In the latest draft of the C standard, 6.2.3.2 states
# An integer may be converted to any pointer type. Except as
# previously specified, the result is implementation-defined,
# might not be correctly aligned, might not point to an entity of
# the referenced type, and might be a trap representation.
#
# Any pointer type may be converted to an integer type. Except as
# previously specified, the result is implementation-defined. If the
# result cannot be represented in the integer type, the behavior is
# undefined. The result need not be in the range of values of any
# integer type.
So, if the documentation of yor C compiler tells you that you can
freely convert between some ints and some pointer, you're likely
to get the results you want. You'll be locked to that compiler,
though, but it might just work, unless it doesn't.
But of course, C++ isn't C, and I don't know C++ well enough
to tell you what is dangerous there and what isn't.
As for logicals, that's a can of worms. Old Fortran did not specify
the values for logicals, and different compilers supplied different interpretations - reading true or false written by one compiler did
not necessarily represent a true or false value in another compiler.
There are at least three conventions: Some compilers use C's
"nonzero is true" convention. Others just test for the least
significant bit. And there is a faction which just allows
for (in representation) 0 and 1, and anything else is undefined,
and liable to break if you test for a .eqv. b where a has the
numerical value of 1 and b of 2.
Soo... not sure what your code actually looks like, but intermixing
logicals with is asking for interesting effects.
I feel your pain regarding your extensive use of those nonstandard
features, which include structures and automatic zero initialization, as
you have told us about many times here. I have used those features
myself on a much smaller scale back in the 1970s, so I know their
appeal. As I understand your situation now, your code only works with a single fortran compiler and a single operating system. I certainly do
not claim to know what you should do now to dig out of that hole, but I
do hope you succeed with whatever path you choose.
On Wednesday, November 30, 2022 at 11:45:26 PM UTC-8, Ron Shepard wrote:
(snip)
I feel your pain regarding your extensive use of those nonstandard
features, which include structures and automatic zero initialization, as
you have told us about many times here. I have used those features
myself on a much smaller scale back in the 1970s, so I know their
appeal. As I understand your situation now, your code only works with a
single fortran compiler and a single operating system. I certainly do
not claim to know what you should do now to dig out of that hole, but I
do hope you succeed with whatever path you choose.
For problems this size, there is never an easy answer.
It seems that some answers are less helpful, and seem not
to hope for success. Presumably more than one person has
worked on this over the years. Even decisions based on the best
choice at the time, might turn out later to have been wrong.
So, yes, good luck!
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 159 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 99:30:38 |
| Calls: | 3,209 |
| Files: | 10,563 |
| Messages: | 3,009,786 |