Path: csiph.com!1.us.feeder.erje.net!3.us.feeder.erje.net!feeder.erje.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx33.iad.POSTED!not-for-mail X-newsreader: xrn 9.03-beta-14-64bit Sender: scott@dragon.sl.home (Scott Lurndal) From: scott@slp53.sl.home (Scott Lurndal) Reply-To: slp53@pacbell.net Subject: Re: converting a 700,000+ line Fortran 77 plus 50,000+ line C++ program to C++, part 1 Newsgroups: comp.lang.fortran,comp.lang.c++ References: <84aed433-6586-41af-b3d0-28dd17f9450bn@googlegroups.com> <35aea1e9-10eb-4949-993f-70eaab092237n@googlegroups.com> Lines: 64 Message-ID: X-Complaints-To: abuse@usenetserver.com NNTP-Posting-Date: Thu, 27 Oct 2022 14:54:43 UTC Organization: UsenetServer - www.usenetserver.com Date: Thu, 27 Oct 2022 14:54:43 GMT X-Received-Bytes: 3626 Xref: csiph.com comp.lang.fortran:73791 comp.lang.c++:87164 Lynn McGuire writes: >On 10/26/2022 7:59 PM, gah4 wrote: >> 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. >> >> (snip) >>> 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. >> >> 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 :-)