| Lynn McGuire <lynnmcguire5@gmail.com>: Oct 26 11:47PM -0500 On 10/26/2022 7:59 PM, gah4 wrote: >> really points the direction to me. > 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 ? Lynn |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 26 10:26PM -0700 On 10/23/2022 3:16 PM, Lynn McGuire wrote: > 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. Is the code modular so you can port and test just a part of it? |
| scott@slp53.sl.home (Scott Lurndal): Oct 27 02:54PM >> 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 wouldn't have written a 750,000 line engine in any language; not as a single module anyway. You can probably do the whole thing in something like MatLab in a couple hundred lines :-) |
| Thomas Koenig <tkoenig@netcologne.de>: Oct 27 06:21PM > 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. > 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. > 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. > 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." |
| Lynn McGuire <lynnmcguire5@gmail.com>: Oct 27 02:01PM -0500 On 10/27/2022 12:26 AM, Chris M. Thomasson wrote: >> of my programmers thinks that we will be lucky to get a complete build >> by late 2024. > Is the code modular so you can port and test just a part of it? Somewhat. And yes, that is what I am doing. Port for a while and then test. Port for a while and then test. I have already completed the first cycle. No showstoppers. Lynn |
| Lynn McGuire <lynnmcguire5@gmail.com>: Oct 27 02:07PM -0500 On 10/27/2022 3:51 AM, gah4 wrote: > of C++ code. Not that it is necessary to do that, but some do. > Now, since Fortran 77 doesn't do that, I suspect that your program > doesn't, but just to be sure. I can write Fortran in any language. <grin>. The only real features of C++ that I am using is the strong data typing and the polymorphism. The strong data typing helps a lot even though it sometimes invokes strong language from the programmer. When we ported our Windows user interface from Smalltalk to C++ back in 2001, we went from untyped variables to strongly typed. That really helped with the port. The amount of code increased from 300,000 lines of Smalltalk to 450,000 lines of C++. And it ran 100 times faster since the C++ was not interpreted and not garbage collected like the Smalltalk code. Thanks, Lynn |
| Lynn McGuire <lynnmcguire5@gmail.com>: Oct 27 02:08PM -0500 On 10/27/2022 9:54 AM, Scott Lurndal wrote: > not as a single module anyway. > You can probably do the whole thing in something like MatLab > in a couple hundred lines :-) I wish. The thermodynamic flash is over 300,000 lines of F77 code and 2,000+ subroutines by itself. Lynn |
| legalize+jeeves@mail.xmission.com (Richard): Oct 27 08:42PM [Please do not mail me a copy of your followup] Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code >We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++ >lines of code engineering software product to C++. [...] Lynn, I dropped you a private email with a couple suggestions, but I always seem to end up in people's spam folders, so just a little FYI publicly. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| 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