From Newsgroup: comp.lang.c++

On 4/11/2025 11:00 AM, Steven G. Kargl wrote:

On Fri, 11 Apr 2025 11:37:17 +0200, Bonita Montero wrote:

Am 09.04.2025 um 21:48 schrieb Lynn McGuire:

No, we want to get away from compiling and linking directly.
That is what we use with Open Watcom F77 and C++.

The Watcom stuff is totally outdated.
Is there no way to get something newer ?

You must be new here in c.l.f. Lynn has been converting
his 700 KLOC of Fortran to C++ for 2+ decades. It seems
his code, which clearly isn't Fortran, can only be compiled
by a Watcom language compiler. For those playing along,
that's roughy converting 140 lines of code per workday
with 2 weeks for good behavior (ie., 700000 / (50*5*20)).

I am now well over conversion of 200,000 lines of my 800,000+ Fortran
66/77 code to C++. Things are going well other than customer demands
for new features constantly interrupting things. And fixing old bugs of course. I am now shooting for completion by Summer 2027.

The C++ conversion of the F66 / F77 code has unearthed innumerable old
bugs. It is a wonder that the code has ever worked.

My conversion tool, a customized version of F2C, converts all Fortran character variables to straight C char variables. I would really like
to automatically convert these to C++ std::string variables as I am
doing that by hand. This is the main thing slowing me down.

Since I have a builtin Fortran 66 compiler and interpreter in my
software, I may be writing an automated Fortran format and write
statement processor anyway in the near future. So I am thinking about updating my conversion tool.

Lynn

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

In <118sel3$dop4$1@dont-email.me> Lynn McGuire <lynnmcguire5@gmail.com> wrote:

On 4/11/2025 11:00 AM, Steven G. Kargl wrote:

On Fri, 11 Apr 2025 11:37:17 +0200, Bonita Montero wrote:

Am 09.04.2025 um 21:48 schrieb Lynn McGuire:

Why is a year-old thread popping up with nothing new added?
--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss (404) GoogleGroup (404 http://twovoyagers.com/improve-usenet.org/).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 2026-09-22, Harold Stevens <wookie@bookworm.localdomain> wrote:

In <118sel3$dop4$1@dont-email.me> Lynn McGuire <lynnmcguire5@gmail.com> wrote:

On 4/11/2025 11:00 AM, Steven G. Kargl wrote:

On Fri, 11 Apr 2025 11:37:17 +0200, Bonita Montero wrote:

Am 09.04.2025 um 21:48 schrieb Lynn McGuire:

Why is a year-old thread popping up with nothing new added?

Ooops. Sorry Lynn. I noticed you're updating your progress. Mea culpa ...
--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss (404) GoogleGroup (404 http://twovoyagers.com/improve-usenet.org/).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 9/22/2026 4:58 AM, Harold Stevens wrote:

On 2026-09-22, Harold Stevens <wookie@bookworm.localdomain> wrote:

In <118sel3$dop4$1@dont-email.me> Lynn McGuire <lynnmcguire5@gmail.com> wrote:

On 4/11/2025 11:00 AM, Steven G. Kargl wrote:

On Fri, 11 Apr 2025 11:37:17 +0200, Bonita Montero wrote:

Am 09.04.2025 um 21:48 schrieb Lynn McGuire:

Why is a year-old thread popping up with nothing new added?

Ooops. Sorry Lynn. I noticed you're updating your progress. Mea culpa ...

No worries!

Lynn

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

On 4/11/2025 11:00 AM, Steven G. Kargl wrote:

On Fri, 11 Apr 2025 11:37:17 +0200, Bonita Montero wrote:

Am 09.04.2025 um 21:48 schrieb Lynn McGuire:

No, we want to get away from compiling and linking directly.
That is what we use with Open Watcom F77 and C++.

The Watcom stuff is totally outdated.
Is there no way to get something newer ?

You must be new here in c.l.f. Lynn has been converting
his 700 KLOC of Fortran to C++ for 2+ decades. It seems
his code, which clearly isn't Fortran, can only be compiled
by a Watcom language compiler. For those playing along,
that's roughy converting 140 lines of code per workday
with 2 weeks for good behavior (ie., 700000 / (50*5*20)).

I am now well over conversion of 200,000 lines of my 800,000+ Fortran
66/77 code to C++. Things are going well other than customer demands
for new features constantly interrupting things. And fixing old bugs of course. I am now shooting for completion by Summer 2027.

The C++ conversion of the F66 / F77 code has unearthed innumerable old
bugs. It is a wonder that the code has ever worked.

I am not very surprised at that.

Out of curiosity: What types of errors did you find? Was it logic
errors (although those would have been hard to find by conversion
to a different language, unless this caused you to look at old code),
argument mismatch errors, errors in memory handling through COMMON
blocks, ... ?

(I still find it a pity that you didn't do the converersion to
modern Fortran)

My conversion tool, a customized version of F2C, converts all Fortran character variables to straight C char variables. I would really like
to automatically convert these to C++ std::string variables as I am
doing that by hand. This is the main thing slowing me down.

Changing to printf and friends, or cin/cout? (I find the latter
amost unreadable).

Since I have a builtin Fortran 66 compiler and interpreter in my
software, I may be writing an automated Fortran format and write
statement processor anyway in the near future. So I am thinking about updating my conversion tool.

That probably makes a lot of sense.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 9/24/2026 11:14 AM, Thomas Koenig wrote:

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

On 4/11/2025 11:00 AM, Steven G. Kargl wrote:

On Fri, 11 Apr 2025 11:37:17 +0200, Bonita Montero wrote:

Am 09.04.2025 um 21:48 schrieb Lynn McGuire:

No, we want to get away from compiling and linking directly.
That is what we use with Open Watcom F77 and C++.

The Watcom stuff is totally outdated.
Is there no way to get something newer ?

You must be new here in c.l.f. Lynn has been converting
his 700 KLOC of Fortran to C++ for 2+ decades. It seems
his code, which clearly isn't Fortran, can only be compiled
by a Watcom language compiler. For those playing along,
that's roughy converting 140 lines of code per workday
with 2 weeks for good behavior (ie., 700000 / (50*5*20)).

I am now well over conversion of 200,000 lines of my 800,000+ Fortran
66/77 code to C++. Things are going well other than customer demands
for new features constantly interrupting things. And fixing old bugs of
course. I am now shooting for completion by Summer 2027.

The C++ conversion of the F66 / F77 code has unearthed innumerable old
bugs. It is a wonder that the code has ever worked.

I am not very surprised at that.

Out of curiosity: What types of errors did you find? Was it logic
errors (although those would have been hard to find by conversion
to a different language, unless this caused you to look at old code), argument mismatch errors, errors in memory handling through COMMON
blocks, ... ?

(I still find it a pity that you didn't do the converersion to
modern Fortran)

My conversion tool, a customized version of F2C, converts all Fortran
character variables to straight C char variables. I would really like
to automatically convert these to C++ std::string variables as I am
doing that by hand. This is the main thing slowing me down.

Changing to printf and friends, or cin/cout? (I find the latter
amost unreadable).

Since I have a builtin Fortran 66 compiler and interpreter in my
software, I may be writing an automated Fortran format and write
statement processor anyway in the near future. So I am thinking about
updating my conversion tool.

That probably makes a lot of sense.

Most of the code errors that I have found are undersized arrays and
wrong types for variables. An integer where the variable should be
floating point. And many, many argument mismatches because our Fortran
did not require you to have the same variable type in the callee as the caller. C++ is much more strongly typed than old Fortran 66/77 is, I do
not know about Fortran 90.

I have my own asString methods and apply them to all variables to be
printed. I use a std::string to build strings to be printed:

Fortran:
write (screenbuffer,3890) sumbvdmas, total_flai_calls
3890 format ('WARNING: mass out = ', G14.7, ' lb/hr, call # ', i10, ' (flai)')
call scrwri (screenbuffer)

C++:
str = "WARNING: mass out = " + asString (sumbvdmas, 14, 7) + "
lb/hr, call # " + asString (total_flai_calls) + " (flai)";
scrwri (str);

Lynn

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 9/21/2026 4:29 PM, Lynn McGuire wrote:

On 4/11/2025 11:00 AM, Steven G. Kargl wrote:

On Fri, 11 Apr 2025 11:37:17 +0200, Bonita Montero wrote:

Am 09.04.2025 um 21:48 schrieb Lynn McGuire:

No, we want to get away from compiling and linking directly.
That is what we use with Open Watcom F77 and C++.

The Watcom stuff is totally outdated.
Is there no way to get something newer ?

You must be new here in c.l.f.-a Lynn has been converting
his 700 KLOC of Fortran to C++ for 2+ decades.-a It seems
his code, which clearly isn't Fortran, can only be compiled
by a Watcom language compiler.-a For those playing along,
that's roughy converting 140 lines of code per workday
with 2 weeks for good behavior (ie., 700000 / (50*5*20)).

I am now well over conversion of 200,000 lines of my 800,000+ Fortran
66/77 code to C++.-a Things are going well other than customer demands
for new features constantly interrupting things.

[...]

Tell them. Please, let me port then when thats done, we can all take a
good look, and make new features. ;^o

Are they hitting you with you better be ready by then? ;^o
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Thu, 24 Sep 2026 16:14:14 -0000 (UTC), Thomas Koenig wrote:

Changing to printf and friends, or cin/cout? (I find the latter
amost unreadable).

printf/snprintf/etc is a surprisingly good way of dealing with complex
output formatting requirements. It does represent a big hole in
typesafeness in statically-typed languages, but it works fine in dynamically-typed ones.

Another useful feature of printf-style formatting is that it allows
reordering the input arguments in the output string, which cout does
not. This can be important for internationalization/localization
purposes, to let you write one set of code that will work equally well
in all locales, with output being driven by locale-specific format
strings. cout doesnrCOt lend itself well to that approach.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
[...]

Another useful feature of printf-style formatting is that it allows reordering the input arguments in the output string, which cout does
not. This can be important for internationalization/localization
purposes, to let you write one set of code that will work equally well
in all locales, with output being driven by locale-specific format
strings. cout doesnrCOt lend itself well to that approach.

That's a common extension, but not a feature of printf as specified by
the C and C++ standards.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

On 9/24/2026 11:14 AM, Thomas Koenig wrote:

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

The C++ conversion of the F66 / F77 code has unearthed innumerable old
bugs. It is a wonder that the code has ever worked.

I am not very surprised at that.

Out of curiosity: What types of errors did you find? Was it logic
errors (although those would have been hard to find by conversion
to a different language, unless this caused you to look at old code),
argument mismatch errors, errors in memory handling through COMMON
blocks, ... ?

[...]

Most of the code errors that I have found are undersized arrays and
wrong types for variables. An integer where the variable should be
floating point.

Ah yes. That can introduce a *lot* of errors. I remember code
that I once saw where somebody had an implicitly typed variable
NU for the Nu|felt number... Plus, of course, the classic of
writing RE**(1/5).

But even if you are still in the conversion step, it might not
hurt to do something like this:

SUBROUTINE FOO(A,B,N)
N = A * B
END

will give you, with

gfortran -Wall -Wextra -Werror -Wconversion-extra foo.f

foo.f:2:10:

2 | N = A * B
| 1
Error: Possible change of value in conversion from REAL(4) to INTEGER(4) at (1) [-Werror=conversion]
f951: all warnings being treated as errors

Converting to C++ will not catch this (I believe, it has the same
rules as C there), so it might be a good idea to run this to
catch further errors.

And many, many argument mismatches because our Fortran
did not require you to have the same variable type in the callee as the caller.

There are tools for this, which I think I mentioned earlier.
ftnchek is one of them, but modern compilers also check much
more than they used to. Example, goes with the snipped above:

PROGRAMME MAIN
CALL SUB(1.0,2.0,A)
PRINT *,A
END

gfortran -O -flto main.f foo.f
main.f:2:14: warning: type of 'foo' does not match original declaration [-Wlto-type-mismatch]
2 | CALL FOO(1.0,2.0,A)
| ^
foo.f:1:7: note: 'foo' was previously declared here
1 | SUBROUTINE FOO(A,B,N)
| ^
foo.f:1:7: note: code may be misoptimized unless '-fno-strict-aliasing' is used

And if you put both in a single file, you will get

combined.f:2:72:

2 | CALL FOO(1.0,2.0,A)
| 1
Error: Type mismatch in argument 'n' at (1); passed REAL(4) to INTEGER(4)

C++ is much more strongly typed than old Fortran 66/77 is, I do
not know about Fortran 90.

You can still use the old stuff in Fortran 90+, but if you put your
code in modules, it gets checked.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
[...]

Another useful feature of printf-style formatting is that it allows
reordering the input arguments in the output string, which cout does
not. This can be important for internationalization/localization
purposes, to let you write one set of code that will work equally well
in all locales, with output being driven by locale-specific format
strings. cout doesnrCOt lend itself well to that approach.

That's a common extension, but not a feature of printf as specified by
the C and C++ standards.

It is, however, specified by POSIX.

--- Synchronet 3.22a-Linux NewsLink 1.2