Is there a good C++ converter to Fortran?
--
Dieter Britz

On Monday, August 28, 2023 at 11:37:28 AM UTC+2, db wrote:
> Is there a good C++ converter to Fortran?
> --
> Dieter Britz

Just to clarify: you do mean a tool to convert C++ code to Fortran code? Not a tool to make the connection between C++ code and Fortran code work smoothly?

Regards,

Arjen

On Monday, August 28, 2023 at 2:37:28 AM UTC-7, db wrote:
> Is there a good C++ converter to Fortran?

There might be some work on C to Fortran conversion.
(Maybe not enough to qualify as "good", though.)

The OO extensions to Fortran are more recent, and though they are
being implemented in compilers, maybe not completely debugged yet.
That would complicate the conversion of OO C++ to OO Fortran.

The actual design of the object-oriented parts of the two language
are not especially close, either.

On 28.08.2023 12.27, Arjen Markus wrote:
> On Monday, August 28, 2023 at 11:37:28 AM UTC+2, db wrote:
>> Is there a good C++ converter to Fortran?
>> --
>> Dieter Britz
>
> Just to clarify: you do mean a tool to convert C++ code to Fortran code? Not a tool to make the connection between C++ code and Fortran code work smoothly?
>
> Regards,
>
> Arjen
That's what I wanted, but maybe I should learn how to call C++
code from Fortran instead.
--
Dieter Britz

On Tuesday, August 29, 2023 at 7:21:30 AM UTC-7, db wrote:
> On 28.08.2023 12.27, Arjen Markus wrote:
> > On Monday, August 28, 2023 at 11:37:28 AM UTC+2, db wrote:
> >> Is there a good C++ converter to Fortran?
> >> --
> >> Dieter Britz
> >
> > Just to clarify: you do mean a tool to convert C++ code to Fortran code? Not a tool to make the connection between C++ code and Fortran code work smoothly?
> >
> > Regards,
> >
> > Arjen
> That's what I wanted, but maybe I should learn how to call C++
> code from Fortran instead.
> --
> Dieter Britz
That prompts me to ask if the Fortran C Interoperability is sufficient to handle the needs of calling C++.

On Tuesday, August 29, 2023 at 6:56:51 PM UTC+2, Jeff Ryman wrote:
> On Tuesday, August 29, 2023 at 7:21:30 AM UTC-7, db wrote:
> > On 28.08.2023 12.27, Arjen Markus wrote:
> > > On Monday, August 28, 2023 at 11:37:28 AM UTC+2, db wrote:
> > >> Is there a good C++ converter to Fortran?
> > >> --
> > >> Dieter Britz
> > >
> > > Just to clarify: you do mean a tool to convert C++ code to Fortran code? Not a tool to make the connection between C++ code and Fortran code work smoothly?
> > >
> > > Regards,
> > >
> > > Arjen
> > That's what I wanted, but maybe I should learn how to call C++
> > code from Fortran instead.
> > --
> > Dieter Britz
> That prompts me to ask if the Fortran C Interoperability is sufficient to handle the needs of calling C++.

The interface would have to use the 'extern "C"' construction, so any C++ routine (function) to be called has to follow the C conventions. Other than that (and the limitations that puts on the interfacing), yes, I would say so.

Regards,

Arjen

On 8/29/2023 11:56 AM, Jeff Ryman wrote:
> On Tuesday, August 29, 2023 at 7:21:30 AM UTC-7, db wrote:
>> On 28.08.2023 12.27, Arjen Markus wrote:
>>> On Monday, August 28, 2023 at 11:37:28 AM UTC+2, db wrote:
>>>> Is there a good C++ converter to Fortran?
>>>> --
>>>> Dieter Britz
>>>
>>> Just to clarify: you do mean a tool to convert C++ code to Fortran code? Not a tool to make the connection between C++ code and Fortran code work smoothly?
>>>
>>> Regards,
>>>
>>> Arjen
>> That's what I wanted, but maybe I should learn how to call C++
>> code from Fortran instead.
>> --
>> Dieter Britz
> That prompts me to ask if the Fortran C Interoperability is sufficient to handle the needs of calling C++.

I do it all the time. I have 5,000 subroutines, 720,000 lines of F77
code, and 50,000 lines of C++ code.

Lynn

On Tuesday, August 29, 2023 at 10:41:56 AM UTC-7, Arjen Markus wrote:

(snip)

> The interface would have to use the 'extern "C"' construction, so any C++ routine
> (function) to be called has to follow the C conventions.
> Other than that (and the limitations that puts on the interfacing), yes, I would say so.

There has been very little discussion here on OO Fortran.

If one asks about C++, do we assume that they mean the OO features?

I did used to know people who wrote OO code in Fortran IV, (possibly using
extensions to Fortran 66). I didn't know about OO at the time, though.

It is then possible to write OO code in C, though with a little extra work that
you don't need to do with C++.

I suspect you could hand translate small amounts of OO C++ code to OO Fortran.
That should probably be done to better understand how OO Fortran works.

But larger amounts would be a lot of work!

As well as I know it, any maybe not all that well, the features don't all
directly translate.

On 8/29/2023 6:19 PM, gah4 wrote:
> On Tuesday, August 29, 2023 at 10:41:56 AM UTC-7, Arjen Markus wrote:
>
> (snip)
>
>> The interface would have to use the 'extern "C"' construction, so any C++ routine
>> (function) to be called has to follow the C conventions.
>> Other than that (and the limitations that puts on the interfacing), yes, I would say so.
>
>
> There has been very little discussion here on OO Fortran.
>
> If one asks about C++, do we assume that they mean the OO features?
>
> I did used to know people who wrote OO code in Fortran IV, (possibly using
> extensions to Fortran 66). I didn't know about OO at the time, though.
>
> It is then possible to write OO code in C, though with a little extra work that
> you don't need to do with C++.

Isn't a single derived type an "OO" concept? I'm still not a fan of
derived types for procedure arguments (e.g. the win32 API...yuck). I
use the extensively for internal "global/common" purposes though.

db <dieterhansbritz@gmail.com> schrieb:
> Is there a good C++ converter to Fortran?

Due to the ongoing feature stampede of C++, such a converter would
be extremely hard to write for the general case in a way that would
create maintainable code.

A few examples (far from complete, I am not a C++ expert): Unlike
C++, Fortran does not have templates, multiple inheritance, unsigned
numbers (which I think is an omission that should be rectified) etc.

On Tuesday, August 29, 2023 at 6:47:49 PM UTC-7, Gary Scott wrote:

(snip, I wrote)

> > It is then possible to write OO code in C, though with a little extra work that
> > you don't need to do with C++.

> Isn't a single derived type an "OO" concept? I'm still not a fan of
> derived types for procedure arguments (e.g. the win32 API...yuck). I
> use the extensively for internal "global/common" purposes though.

As well as I know it, derived types are related to structures in some other
languages. I first knew them in PL/I, where I believe they came from COBOL..

I believe the Fortran standard also uses the word structure, so I sometimes
call them that.

I don't know the history of OO, and especially when the actual term originated.
I do remember someone telling me about Simula sometime before I knew
about C, though wasn't interested at the time.

I also don't know the history of COBOL so well, but it does seem that they idea
of keeping disparate date together is important.

Looking at it now, you have to wonder what took Fortran so long.

But a common idea in a COBOL program might be the information about
an employee, such as name and salary, that would be kept together.
They would then be read from a file (or in the early days, card) together,
and operated on sometimes as a unit.

PL/I has stream and record I/O, where STREAM corresponds to Fortran
FORMATTED, and RECORD to Fortran UNFORMATTED. RECORD I/O
statements only read/write one variable, which is commonly a structure.
I believe that also came from COBOL.

Note that is especially convenient for I/O, as the data is together.
In the usual case, it can be copied to/from byte by byte, without knowing
what the data type is.

PL/I also has locate-mode I/O, where you access data directly in the I/O
buffer, saving the need to copy it. I suspect also from COBOL, though
I don't know that one.

Also, COBOL only has one-dimensional arrays. But you can have arrays
of structures of arrays of ..., so the effect of higher dimensions.
PL/I has, I believe again from COBOL, some convenience in array access.

If you have a structure array that might be accessed as x(i).y(j).z(k), the
compiler can figure it out if you instead say: x.y.z(i, j, k).
Even more, assuming it is not ambiguous, partial qualification
allows for z(i, j, k) where the compiler assumes the x.y. part.
(PL/I allows for multiple dimensions, but also moving subscripts
around and partial qualification.)

It seems that some of the OO ideas might have originated in COBOL,
and slowly spread until they got named, into other languages.

gah4 <gah4@u.washington.edu> writes:
>I don't know the history of OO, and especially when the
>actual term originated.

While Simula actually implemented many ideas of OOP,
the term "object-oriented" was coined by Alan Kay.

Since C++ was mentioned in this discussion, I have to
quote Alan Kay:

|I invented the term "object-oriented" and I can tell you I did
|not have C++ in mind.

.

>It seems that some of the OO ideas might have originated in COBOL,
>and slowly spread until they got named, into other languages.

COBOL indeed is know for its "computerization of business records"
(Sebasta). But this is not OOP.

Crucial parts of OOP that are still missing from records are:

- abstract data types, that allow to hide implementation details;

- polymorphism, that allows abstract calls (i.e., when the call
is written, the type of the object is not specified); and

- code organization that make it easy to add new types (while
procedural programming makes it easy to add new procedures).

On 8/30/2023 12:13 PM, gah4 wrote:
> On Tuesday, August 29, 2023 at 6:47:49 PM UTC-7, Gary Scott wrote:
>
> (snip, I wrote)
>
>>> It is then possible to write OO code in C, though with a little extra work that
>>> you don't need to do with C++.
>
>> Isn't a single derived type an "OO" concept? I'm still not a fan of
>> derived types for procedure arguments (e.g. the win32 API...yuck). I
>> use the extensively for internal "global/common" purposes though.
>
> As well as I know it, derived types are related to structures in some other
> languages. I first knew them in PL/I, where I believe they came from COBOL.
>
> I believe the Fortran standard also uses the word structure, so I sometimes
> call them that.
>
> I don't know the history of OO, and especially when the actual term originated.
> I do remember someone telling me about Simula sometime before I knew
> about C, though wasn't interested at the time.
> SNIP

Smalltalk was the more influential.

On Wednesday, August 30, 2023 at 12:12:35 PM UTC-7, Gary Scott wrote:

(snip, I wrote)
> > I don't know the history of OO, and especially when the actual term originated.
> > I do remember someone telling me about Simula sometime before I knew
> > about C, though wasn't interested at the time.

> SNIP
>
> Smalltalk was the more influential.

https://en.wikipedia.org/wiki/Simula

seems to suggest that Simula influenced Smalltalk, and originate the
object oriented ideas.

https://en.wikipedia.org/wiki/Record_(computer_science)

attributes the idea of a record to punched card days, and the idea of
programming language support for, the structure data type
to COBOL.

On 8/30/2023 2:12 PM, Gary Scott wrote:
> On 8/30/2023 12:13 PM, gah4 wrote:
>> On Tuesday, August 29, 2023 at 6:47:49 PM UTC-7, Gary Scott wrote:
>>
>> (snip, I wrote)
>>
>>>> It is then possible to write OO code in C, though with a little
>>>> extra work that
>>>> you don't need to do with C++.
>>
>>> Isn't a single derived type an "OO" concept? I'm still not a fan of
>>> derived types for procedure arguments (e.g. the win32 API...yuck). I
>>> use the extensively for internal "global/common" purposes though.
>>
>> As well as I know it, derived types are related to structures in some
>> other
>> languages.  I first knew them in PL/I, where I believe they came from
>> COBOL.
>>
>> I believe the Fortran standard also uses the word structure, so I
>> sometimes
>> call them that.
>>
>> I don't know the history of OO, and especially when the actual term
>> originated.
>> I do remember someone telling me about Simula sometime before I knew
>> about C, though wasn't interested at the time.
>> SNIP
>
> Smalltalk was the more influential.

We used to have an app written in Smalltalk. C++ and F77 run about 100X
faster than Smalltalk. I converted our Smalltalk app to C++ and never
looked back.

Lynn

On Thursday, 31 August 2023 at 03:13:45 UTC+10, gah4 wrote:
> On Tuesday, August 29, 2023 at 6:47:49 PM UTC-7, Gary Scott wrote:
>
> (snip, I wrote)
> > > It is then possible to write OO code in C, though with a little extra work that
> > > you don't need to do with C++.
>
> > Isn't a single derived type an "OO" concept? I'm still not a fan of
> > derived types for procedure arguments (e.g. the win32 API...yuck). I
> > use the extensively for internal "global/common" purposes though.
> As well as I know it, derived types are related to structures in some other
> languages. I first knew them in PL/I, where I believe they came from COBOL.
>
> I believe the Fortran standard also uses the word structure, so I sometimes
> call them that.
>
> I don't know the history of OO, and especially when the actual term originated.
> I do remember someone telling me about Simula sometime before I knew
> about C, though wasn't interested at the time.
>
> I also don't know the history of COBOL so well, but it does seem that they idea
> of keeping disparate date together is important.
>
> Looking at it now, you have to wonder what took Fortran so long.
>
> But a common idea in a COBOL program might be the information about
> an employee, such as name and salary, that would be kept together.
> They would then be read from a file (or in the early days, card) together,
> and operated on sometimes as a unit.
>
> PL/I has stream and record I/O, where STREAM corresponds to Fortran
> FORMATTED, and RECORD to Fortran UNFORMATTED. RECORD I/O
> statements only read/write one variable, which is commonly a structure.
> I believe that also came from COBOL.
>
> Note that is especially convenient for I/O, as the data is together.
> In the usual case, it can be copied to/from byte by byte, without knowing
> what the data type is.
>
> PL/I also has locate-mode I/O, where you access data directly in the I/O
> buffer, saving the need to copy it. I suspect also from COBOL, though
> I don't know that one.
>
> Also, COBOL only has one-dimensional arrays. But you can have arrays
> of structures of arrays of ..., so the effect of higher dimensions.
> PL/I has, I believe again from COBOL, some convenience in array access.
..
Multidimensional arrays in PL/I came from FORTRAN and ALGOL,
but whole array operations and cross-sections of arrays were a
new concept that came with IBM's first PL/I compiler in c, 1966.
..
The latter features were adopted 25 years later into Fortran 90.
..
> If you have a structure array that might be accessed as x(i).y(j).z(k), the
> compiler can figure it out if you instead say: x.y.z(i, j, k).
> Even more, assuming it is not ambiguous, partial qualification
> allows for z(i, j, k) where the compiler assumes the x.y. part.
> (PL/I allows for multiple dimensions, but also moving subscripts
> around and partial qualification.)
>
> It seems that some of the OO ideas might have originated in COBOL,
> and slowly spread until they got named, into other languages.

On Wednesday, August 30, 2023 at 7:45:01 PM UTC-7, robin vowels wrote:

(snip)

> Multidimensional arrays in PL/I came from FORTRAN and ALGOL,
> but whole array operations and cross-sections of arrays were a
> new concept that came with IBM's first PL/I compiler in c, 1966.
> The latter features were adopted 25 years later into Fortran 90.
Which reminds me of one PL/I feature that Fortran still doesn't have:

Structure expressions.

You can do operations on structures, either by structure shape,
so member by member, or by member name.

Neither has made it to Fortran.

On 8/30/2023 10:29 PM, gah4 wrote:
> On Wednesday, August 30, 2023 at 7:45:01 PM UTC-7, robin vowels wrote:
>
> (snip)
>
>> Multidimensional arrays in PL/I came from FORTRAN and ALGOL,
>> but whole array operations and cross-sections of arrays were a
>> new concept that came with IBM's first PL/I compiler in c, 1966.
>
>> The latter features were adopted 25 years later into Fortran 90.
>
> Which reminds me of one PL/I feature that Fortran still doesn't have:
>
> Structure expressions.
>
> You can do operations on structures, either by structure shape,
> so member by member, or by member name.
>
> Neither has made it to Fortran.

I am confused, what are structure expressions ?

Just about every Fortran compiler supports the old Dec Structures from
the 1970s that never made it into the official language definition. I
am removing them from our code right now in fact as a part of my 4th
Intel Fortran port.

Lynn

On Thursday, August 31, 2023 at 12:49:29 PM UTC-7, Lynn McGuire wrote:

(snip, I wrote)

> > You can do operations on structures, either by structure shape,
> > so member by member, or by member name.
> > Neither has made it to Fortran.

> I am confused, what are structure expressions ?
> Just about every Fortran compiler supports the old Dec Structures from
> the 1970s that never made it into the official language definition. I
> am removing them from our code right now in fact as a part of my 4th
> Intel Fortran port.
Like array expressions, except structures instead of arrays.

You can have:

A = B + C

where A, B, and C are arrays, added element by element.

PL/I will add structures member by member.
Or any other operation, as you would expect with arrays.

Y = SQRT(X)

F = SIN(G)**2 + COS(G)**2

It can make more or less sense, depending on the types of the members.

type :: vector
real :: x, y, z
end type

member by member operations should make enough sense in this case.