| Lynn McGuire <lynnmcguire5@gmail.com>: Oct 23 05:16PM -0500 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 |
| Muttley@dastardlyhq.com: Oct 23 07:35AM On Sat, 22 Oct 2022 15:03:44 -0500 >I am porting a 700,000 line Fortran 77 + 50,000 line C++ engineering >software application to pure C++. I am trying to not lose any speed in >the process. 700K lines?? Unless you have some autotranslation tool you'll reach retirement age long before you've finished so the speed will be someone elses problem. |
| JiiPee <kerrttuPoistaTama11@gmail.com>: Oct 23 03:28PM +0300 > speed will be someone elses problem. Yes, optimization is not always the first thing to do. although surely good to keep in mind when developing that makes it easy to change later on faster. |
| Manfred <noname@add.invalid>: Oct 23 08:27PM +0200 On 10/22/2022 10:03 PM, Lynn McGuire wrote: >> doing this kind of programming, when small things are processed. > I am porting a 700,000 line Fortran 77 + 50,000 line C++ engineering > software application to pure C++. This sounds even more as a reason to get to very stable C++ in the process. I'd not want to have any chance of obscure UB hidden deeply in the result code. Which begs the question from the original post: > longint nfac [8]; > fem::str <8> * nfac_str = (fem::str <8> *) nfac; > fem::str <8> is an 8 character object that acts like a Fortran character*8. longint is a long long. Is the cast to/from 8 char string and long long really the best you want here? Unless I am missing something, if you want e.g. to compare those strings, I'd expect that in any decent implementation memcmp is optimized just fine. I am trying to not lose any speed in > the process. Sure, but correctness always comes first. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Oct 23 02:13PM -0500 >> the process. > 700K lines?? Unless you have some autotranslation tool you'll reach retirement > age long before you've finished so the speed will be someone elses problem. I am using a very customized version of the good old f2c tool. I have converted 8,000 lines so far in two weeks. Lynn |
| Michael S <already5chosen@yahoo.com>: Oct 23 03:04PM -0700 On Saturday, October 22, 2022 at 11:04:09 PM UTC+3, Lynn McGuire wrote: > the process. > Thanks, > Lynn What is your motivation for such huge effort? What's wrong with Fortran 77 as long as it is working? And *if* there is really something wrong with working Fortran 77, then why do you port to C++? Is not it easier to port to Modern Fortran (F20xx) or, may be, to port majority of code to Modern Fortran and minority to Julia ? |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 23 03:59PM +0100 Hi! Simulating halt deciders (SHDs) simply do not work. Why? A turing machine should be able to implement ANY algorithm and as such it is an idealisation, an INFINITE STATE MACHINE (ISM) if you will. A simulating halt decider (SHD) can only over be implemented as a FINITE STATE MACHINE (FSM) so is not suitable for a) solving the halting problem or b) refuting the halting problem proofs. Olcott has wasted the last 18 years of his life with what he thinks he invented (SHDs). Alas the deluded dear hasn't even invented a halt decider, all he has invented is a particularly useless form of simulation detector. /Flibble |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 23 04:18PM +0100 On Sun, 23 Oct 2022 10:12:47 -0500 > "head" that, at any point in the machine's operation, is positioned > over one of these cells, and a "state" selected from a *finite set of > states*. https://en.wikipedia.org/wiki/Turing_machine Nope. I am including the tape as part of the machine's state just as we include machine memory as being part of an SHD's state. /Flibble |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment