Does know if anyone updated f2c to convert Fortran data structures to C
data structures ?
https://www.netlib.org/f2c/
Does know if anyone updated f2c to convert Fortran data structures to C
data structures ?
https://www.netlib.org/f2c/
I am contemplating using a modified f2c to convert our 850,000 lines of
F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
Does know if anyone updated f2c to convert Fortran data structures to C
data structures ?
https://www.netlib.org/f2c/
I am contemplating using a modified f2c to convert our 850,000 lines of
F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
I asked the Netlib maintainer and he does not know of any.
Thanks,
Lynn
On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
Does know if anyone updated f2c to convert Fortran data structures to C
data structures ?
https://www.netlib.org/f2c/
I am contemplating using a modified f2c to convert our 850,000 lines of
F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
The F77 code would be better updated to F90 or later form.
Silverfrost f95 can do it as part of the compilation process.
However, it does not transcribe the comments.
Does know if anyone updated f2c to convert Fortran data structures to C
data structures ?
https://www.netlib.org/f2c/
I am contemplating using a modified f2c to convert our 850,000 lines of
F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
I asked the Netlib maintainer and he does not know of any.
Thanks,
Lynn
On 5/27/2022 3:19 AM, Robin Vowels wrote:.
On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
Does know if anyone updated f2c to convert Fortran data structures to C
data structures ?
https://www.netlib.org/f2c/
I am contemplating using a modified f2c to convert our 850,000 lines of
F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
The F77 code would be better updated to F90 or later form.
Silverfrost f95 can do it as part of the compilation process.
However, it does not transcribe the comments.
Please, you are making massive assumptions about my environment..
On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
On 5/27/2022 3:19 AM, Robin Vowels wrote:.
On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
Does know if anyone updated f2c to convert Fortran data structures to C >>>> data structures ?The F77 code would be better updated to F90 or later form.
https://www.netlib.org/f2c/
I am contemplating using a modified f2c to convert our 850,000 lines of >>>> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs. >>>
Silverfrost f95 can do it as part of the compilation process.
However, it does not transcribe the comments.
Please, you are making massive assumptions about my environment..
Is this the project that for years you have been saying that you
want to convert to modern Fortran ?
.
I have had considerable experience in converting F77 and earlier
to F90+ and other languages,
In the process, I uncovered numbers of bugs in the F77 and
earlier sources.
.
Converting your 850,000 lines of code to F90 would be a
massive enough job of itself, let alone to a completely
different language.
.
That's why I suggested updating the code to F90 or later.
On 5/30/2022 8:15 AM, Robin Vowels wrote:...
On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
On 5/27/2022 3:19 AM, Robin Vowels wrote:.
On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
Does know if anyone updated f2c to convert Fortran data structures to C >>>> data structures ?
https://www.netlib.org/f2c/
I am contemplating using a modified f2c to convert our 850,000 lines of >>>> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
The F77 code would be better updated to F90 or later form.
Silverfrost f95 can do it as part of the compilation process.
However, it does not transcribe the comments.
Please, you are making massive assumptions about my environment..
Is this the project that for years you have been saying that you
want to convert to modern Fortran ?
.
I have had considerable experience in converting F77 and earlier
to F90+ and other languages,
In the process, I uncovered numbers of bugs in the F77 and
earlier sources.
Which, people have already noted and worked on.
https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
On 5/30/2022 8:15 AM, Robin Vowels wrote:
On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
On 5/27/2022 3:19 AM, Robin Vowels wrote:.
On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
Does know if anyone updated f2c to convert Fortran data structures
to C
data structures ?
https://www.netlib.org/f2c/
I am contemplating using a modified f2c to convert our 850,000
lines of
F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my
needs.
The F77 code would be better updated to F90 or later form.
Silverfrost f95 can do it as part of the compilation process.
However, it does not transcribe the comments.
Please, you are making massive assumptions about my environment..
Is this the project that for years you have been saying that you
want to convert to modern Fortran ?
.
I have had considerable experience in converting F77 and earlier
to F90+ and other languages,
In the process, I uncovered numbers of bugs in the F77 and
earlier sources.
.
Converting your 850,000 lines of code to F90 would be a
massive enough job of itself, let alone to a completely
different language.
.
That's why I suggested updating the code to F90 or later.
Yes. I have changed my mind. I am going to convert my Fortran
structures to an equivalenced double precision array and a integer*8
array (like I used to have from 1977 to 2002, only an equivalenced
single real array and integer*4 array). Then I am going to start
running my modified f2c on it. F2c already converts integer*8 to a long long int.
I have been running extensive tests on f2c. The generated c code is
very good about converting the algorithms across the language barrier.
And the code is good (there is one array bug though). The translated
read and write code is freaking horrible so I've got to make it better.
Which, people have already noted and worked on.
https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
BTW, my calculation engine is already about 10% C++ code. You cannot do OLE2 in Fortran and my ZIP code is so highly tied to C bit twiddling. I
use extensive C++ glue code for manipulating embedded Excel spreadsheets
in my calculation engine and allowing my users to embed my calculation
engine in their VB, VBA (Excel VB), and C++ code.
Thanks,
Lynn
On 5/30/2022 11:07 PM, Lynn McGuire wrote:
On 5/30/2022 8:15 AM, Robin Vowels wrote:
On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
On 5/27/2022 3:19 AM, Robin Vowels wrote:.
On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
Does know if anyone updated f2c to convert Fortran data structures >>>>>> to C
data structures ?
https://www.netlib.org/f2c/
I am contemplating using a modified f2c to convert our 850,000
lines of
F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my >>>>>> needs.
The F77 code would be better updated to F90 or later form.
Silverfrost f95 can do it as part of the compilation process.
However, it does not transcribe the comments.
Please, you are making massive assumptions about my environment..
Is this the project that for years you have been saying that you
want to convert to modern Fortran ?
.
I have had considerable experience in converting F77 and earlier
to F90+ and other languages,
In the process, I uncovered numbers of bugs in the F77 and
earlier sources.
.
Converting your 850,000 lines of code to F90 would be a
massive enough job of itself, let alone to a completely
different language.
.
That's why I suggested updating the code to F90 or later.
Yes. I have changed my mind. I am going to convert my Fortran
structures to an equivalenced double precision array and a integer*8
array (like I used to have from 1977 to 2002, only an equivalenced
single real array and integer*4 array). Then I am going to start
running my modified f2c on it. F2c already converts integer*8 to a
long long int.
I have been running extensive tests on f2c. The generated c code is
very good about converting the algorithms across the language barrier.
And the code is good (there is one array bug though). The translated
read and write code is freaking horrible so I've got to make it
better. Which, people have already noted and worked on.
https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
BTW, my calculation engine is already about 10% C++ code. You cannot
do OLE2 in Fortran and my ZIP code is so highly tied to C bit
twiddling. I use extensive C++ glue code for manipulating embedded
Excel spreadsheets in my calculation engine and allowing my users to
embed my calculation engine in their VB, VBA (Excel VB), and C++ code.
Thanks,
Lynn
I used DDE, OLE, OLE2, COM from Fortran for decades.
On Tuesday, May 31, 2022 at 12:07:43 AM UTC-4, Lynn McGuire wrote:
On 5/30/2022 8:15 AM, Robin Vowels wrote:...
On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
On 5/27/2022 3:19 AM, Robin Vowels wrote:.
On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
Does know if anyone updated f2c to convert Fortran data structures to C >>>>>> data structures ?
https://www.netlib.org/f2c/
I am contemplating using a modified f2c to convert our 850,000 lines of >>>>>> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
The F77 code would be better updated to F90 or later form.
Silverfrost f95 can do it as part of the compilation process.
However, it does not transcribe the comments.
Please, you are making massive assumptions about my environment..
Is this the project that for years you have been saying that you
want to convert to modern Fortran ?
.
I have had considerable experience in converting F77 and earlier
to F90+ and other languages,
In the process, I uncovered numbers of bugs in the F77 and
earlier sources.
Which, people have already noted and worked on.This URL includes a link to the improved f2c:
https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
http://www.nag.co.uk:70/1h/public
but that link is dead. Does anyone know of an alternative source?
Daniel Feenberg
I did see something somewhat similar in Koenig's ??? Toolbox but I need
to investigate it further:
https://www.ibiblio.org/pub/Linux/devel/lang/fortran/!INDEX.short.html
Regarding f2c - I just checked it on my Ubuntu system, and at least
I/O is broken there, something wrong with the library, I suppose.
I am also not sure if the games it plays for array dummy arguments
generate valid C or not. If you look at
subroutine foo(x,n)
dimension x(n)
x(1) = 1.
end
this gets translated to
/* Subroutine */ int foo_(real *x, integer *n)
{
/* Parameter adjustments */
--x;
/* Function Body */
x[1] = 1.f;
return 0;
} /* foo_ */
but for this another forum wold be more appropriate.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I did see something somewhat similar in Koenig's ??? Toolbox but I need
to investigate it further:
https://www.ibiblio.org/pub/Linux/devel/lang/fortran/!INDEX.short.html
Certainly not mine, I just ported the source to Linux (from a
HP-UX version) after having had good experience with it on MVS.
It originally came from NAG, I believe.
Toolpack has some nice restructuring features, but is _very_ picky
about strict F77 compliance. It does not even grok IMPLICIT NONE,
for example.
Regarding f2c - I just checked it on my Ubuntu system, and at least
I/O is broken there, something wrong with the library, I suppose.
I am also not sure if the games it plays for array dummy arguments
generate valid C or not. If you look at
subroutine foo(x,n)
dimension x(n)
x(1) = 1.
end
this gets translated to
/* Subroutine */ int foo_(real *x, integer *n)
{
/* Parameter adjustments */
--x;
/* Function Body */
x[1] = 1.f;
return 0;
} /* foo_ */
but for this another forum wold be more appropriate.
On 5/31/2022 9:40 AM, Gary Scott wrote:Structures and various operating system APIs allow interoperability. I generally wrote simpler internal APIs to call from Fortran that did the
On 5/30/2022 11:07 PM, Lynn McGuire wrote:
On 5/30/2022 8:15 AM, Robin Vowels wrote:
On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
On 5/27/2022 3:19 AM, Robin Vowels wrote:.
On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote: >>>>>>> Does know if anyone updated f2c to convert Fortran data
structures to C
data structures ?
https://www.netlib.org/f2c/
I am contemplating using a modified f2c to convert our 850,000
lines of
F77 in 5,000 subroutines to C++ code. I will modify f2c to meet
my needs.
The F77 code would be better updated to F90 or later form.
Silverfrost f95 can do it as part of the compilation process.
However, it does not transcribe the comments.
Please, you are making massive assumptions about my environment..
Is this the project that for years you have been saying that you
want to convert to modern Fortran ?
.
I have had considerable experience in converting F77 and earlier
to F90+ and other languages,
In the process, I uncovered numbers of bugs in the F77 and
earlier sources.
.
Converting your 850,000 lines of code to F90 would be a
massive enough job of itself, let alone to a completely
different language.
.
That's why I suggested updating the code to F90 or later.
Yes. I have changed my mind. I am going to convert my Fortran
structures to an equivalenced double precision array and a integer*8
array (like I used to have from 1977 to 2002, only an equivalenced
single real array and integer*4 array). Then I am going to start
running my modified f2c on it. F2c already converts integer*8 to a
long long int.
I have been running extensive tests on f2c. The generated c code is
very good about converting the algorithms across the language
barrier. And the code is good (there is one array bug though). The
translated read and write code is freaking horrible so I've got to
make it better. Which, people have already noted and worked on.
https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
BTW, my calculation engine is already about 10% C++ code. You cannot
do OLE2 in Fortran and my ZIP code is so highly tied to C bit
twiddling. I use extensive C++ glue code for manipulating embedded
Excel spreadsheets in my calculation engine and allowing my users to
embed my calculation engine in their VB, VBA (Excel VB), and C++ code.
Thanks,
Lynn
I used DDE, OLE, OLE2, COM from Fortran for decades.
Sounds like you are better programmer than me. How did you do the wide character strings in OLE2 ?
Lynn
[...]I am also not sure if the games it plays for array dummy arguments
generate valid C or not. If you look at
subroutine foo(x,n)
dimension x(n)
x(1) = 1.
end
this gets translated to
/* Subroutine */ int foo_(real *x, integer *n)
{
/* Parameter adjustments */
--x;
/* Function Body */
x[1] = 1.f;
return 0;
} /* foo_ */
but for this another forum wold be more appropriate.
That is valid C code and a valid pointer.
On 5/31/22 5:04 PM, Lynn McGuire wrote:
[...]
[...]I am also not sure if the games it plays for array dummy arguments
generate valid C or not. If you look at
subroutine foo(x,n)
dimension x(n)
x(1) = 1.
end
this gets translated to
/* Subroutine */ int foo_(real *x, integer *n)
{
/* Parameter adjustments */
--x;
/* Function Body */
x[1] = 1.f;
return 0;
} /* foo_ */
but for this another forum wold be more appropriate.
That is valid C code and a valid pointer.
Others have already stated how it violates the C standard. The reason
for this restriction in C was that the array concept was based on a
segmented memory model. If the first element of the array happened to be
at a segment boundary, then decrementing the pointer meant that the
address was no longer necessarily even within the program's address
space. Depending on the OS, it could be pointing at some part of the OS,
or in a multitasking environment to the memory of another process. Then
later when virtual memory became popular, it could have resulted in page address violations, depending on how exactly the virtual and actual
memory were mapped to each other. Such address computations could
trigger errors, even if the pointers were never referenced. The upper
range of the pointers were accounted for in the language. I think the restriction was that the pointer was allowed to go one unit outside of
the array bound, but it could not be dereferenced once it was there.
There was no such allowance for the lower bound of the array, the
language simply did not allow the pointer outside that range, whether or
not it was later referenced or, as in the above example, incremented
back to within the valid array range.
$.02 -Ron Shepard
On 5/31/2022 1:12 PM, Lynn McGuire wrote:
On 5/31/2022 9:40 AM, Gary Scott wrote:Structures and various operating system APIs allow interoperability. I generally wrote simpler internal APIs to call from Fortran that did the
On 5/30/2022 11:07 PM, Lynn McGuire wrote:
On 5/30/2022 8:15 AM, Robin Vowels wrote:
On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote: >>>>>> On 5/27/2022 3:19 AM, Robin Vowels wrote:
.On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote: >>>>>>>> Does know if anyone updated f2c to convert Fortran data
structures to C
data structures ?
https://www.netlib.org/f2c/
I am contemplating using a modified f2c to convert our 850,000 >>>>>>>> lines of
F77 in 5,000 subroutines to C++ code. I will modify f2c to meet >>>>>>>> my needs.
The F77 code would be better updated to F90 or later form.
Silverfrost f95 can do it as part of the compilation process.
However, it does not transcribe the comments.
Please, you are making massive assumptions about my environment..
Is this the project that for years you have been saying that you
want to convert to modern Fortran ?
.
I have had considerable experience in converting F77 and earlier
to F90+ and other languages,
In the process, I uncovered numbers of bugs in the F77 and
earlier sources.
.
Converting your 850,000 lines of code to F90 would be a
massive enough job of itself, let alone to a completely
different language.
.
That's why I suggested updating the code to F90 or later.
Yes. I have changed my mind. I am going to convert my Fortran
structures to an equivalenced double precision array and a integer*8
array (like I used to have from 1977 to 2002, only an equivalenced
single real array and integer*4 array). Then I am going to start
running my modified f2c on it. F2c already converts integer*8 to a
long long int.
I have been running extensive tests on f2c. The generated c code is
very good about converting the algorithms across the language
barrier. And the code is good (there is one array bug though). The
translated read and write code is freaking horrible so I've got to
make it better. Which, people have already noted and worked on.
https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
BTW, my calculation engine is already about 10% C++ code. You
cannot do OLE2 in Fortran and my ZIP code is so highly tied to C bit
twiddling. I use extensive C++ glue code for manipulating embedded
Excel spreadsheets in my calculation engine and allowing my users to
embed my calculation engine in their VB, VBA (Excel VB), and C++ code. >>>>
Thanks,
Lynn
I used DDE, OLE, OLE2, COM from Fortran for decades.
Sounds like you are better programmer than me. How did you do the
wide character strings in OLE2 ?
Lynn
hard work and made it easier to use.
Yes, very true. I am so used to programming in flat address planes now
that I don't even think about the good old days with segment pointers,
etc. Hopefully, we will never go back to those. After all, I am
starting the journey to 64 bit now.
Others have already stated how it violates the C standard. The reason
for this restriction in C was that the array concept was based on a
segmented memory model.
If the first element of the array happened to be
at a segment boundary, then decrementing the pointer meant that the
address was no longer necessarily even within the program's address
space.
Depending on the OS, it could be pointing at some part of the OS,
or in a multitasking environment to the memory of another process. Then
later when virtual memory became popular, it could have resulted in page address violations, depending on how exactly the virtual and actual
memory were mapped to each other.
Such address computations could
trigger errors, even if the pointers were never referenced. The upper
range of the pointers were accounted for in the language. I think the restriction was that the pointer was allowed to go one unit outside of
the array bound, but it could not be dereferenced once it was there.
There was no such allowance for the lower bound of the array, the
language simply did not allow the pointer outside that range, whether or
not it was later referenced or, as in the above example, incremented
back to within the valid array range.
Reminds me, not so long ago I was working on a Fortran program
from the Fortran 66 days. There was then, and still isn't, short circuit evaluation for logical expressions. This program had lots of
IF(J.LE.100 .AND. X(J).NE.0) ...
(for example) testing the array subscript and testing an array
value in the same IF statement. With many memory models,
that isn't much of a problem, especially if J stays close to the
ends of the array. However, it fails if bounds check is on.
I wanted to check the program for actual bounds errors,
and so had to change a lot of those!
gah4 <ga...@u.washington.edu> schrieb:
Reminds me, not so long ago I was working on a Fortran program
from the Fortran 66 days. There was then, and still isn't, short circuit evaluation for logical expressions. This program had lots of
IF(J.LE.100 .AND. X(J).NE.0) ...
(for example) testing the array subscript and testing an array
value in the same IF statement. With many memory models,
that isn't much of a problem, especially if J stays close to the
ends of the array. However, it fails if bounds check is on.
I wanted to check the program for actual bounds errors,A bit more problematic:
and so had to change a lot of those!
if (x .ne. 0. .and. y/x > 123.) then
...
Conditional expressions in Fortran will make it possible to
rewrite this as (hope I get this right)
if (( .not. x /= 0 ? .false. : y/x > 123.))
but the advantage of readability over
if (x .ne. 0) then
if (x/y > 123.) then
is certainly up for debate.
I have wondered why certain statements are not allowed after the test
in the Fortran one-line if statement. Often I want to write something like
if (i > 0) if (x(i) > 0.0) print*,"i, x(i)=",i,x(i)
On Wednesday, June 1, 2022 at 4:19:26 PM UTC-4, Thomas Koenig wrote:.
gah4 <ga...@u.washington.edu> schrieb:
Reminds me, not so long ago I was working on a Fortran program
from the Fortran 66 days. There was then, and still isn't, short circuit evaluation for logical expressions. This program had lots of
IF(J.LE.100 .AND. X(J).NE.0) ...
(for example) testing the array subscript and testing an array
value in the same IF statement. With many memory models,
that isn't much of a problem, especially if J stays close to the
ends of the array. However, it fails if bounds check is on.
I wanted to check the program for actual bounds errors,A bit more problematic:
and so had to change a lot of those!
if (x .ne. 0. .and. y/x > 123.) then
...
Conditional expressions in Fortran will make it possible to
rewrite this as (hope I get this right)
if (( .not. x /= 0 ? .false. : y/x > 123.))
but the advantage of readability over
if (x .ne. 0) then
if (x/y > 123.) then
is certainly up for debate.I have wondered why certain statements are not allowed after the test
in the Fortran one-line if statement. Often I want to write something like
if (i > 0) if (x(i) > 0.0) print*,"i, x(i)=",i,x(i)
On 5/31/22 5:04 PM, Lynn McGuire wrote:
[...]
[...]I am also not sure if the games it plays for array dummy arguments
generate valid C or not. If you look at
subroutine foo(x,n)
dimension x(n)
x(1) = 1.
end
this gets translated to
/* Subroutine */ int foo_(real *x, integer *n)
{
/* Parameter adjustments */
--x;
/* Function Body */
x[1] = 1.f;
return 0;
} /* foo_ */
but for this another forum wold be more appropriate.
That is valid C code and a valid pointer.
Others have already stated how it violates the C standard. The reason
for this restriction in C was that the array concept was based on a
segmented memory model. If the first element of the array happened to be
at a segment boundary, then decrementing the pointer meant that the
address was no longer necessarily even within the program's address
space. Depending on the OS, it could be pointing at some part of the OS,
or in a multitasking environment to the memory of another process. Then
later when virtual memory became popular, it could have resulted in page address violations, depending on how exactly the virtual and actual
memory were mapped to each other. Such address computations could
trigger errors, even if the pointers were never referenced. The upper
range of the pointers were accounted for in the language. I think the restriction was that the pointer was allowed to go one unit outside of
the array bound, but it could not be dereferenced once it was there.
There was no such allowance for the lower bound of the array, the
language simply did not allow the pointer outside that range, whether or
not it was later referenced or, as in the above example, incremented
back to within the valid array range.
I have wondered why certain statements are not allowed after the test
in the Fortran one-line if statement. Often I want to write something like
if (i > 0) if (x(i) > 0.0) print*,"i, x(i)=",i,x(i)
On Wednesday, June 1, 2022 at 9:31:17 PM UTC-4, Beliavsky wrote:
I have wondered why certain statements are not allowed after the test
in the Fortran one-line if statement. Often I want to write something like >>
if (i > 0) if (x(i) > 0.0) print*,"i, x(i)=",i,x(i)
My understanding is starting Fortran 202X, the following will be conforming code based on the new feature introduction of *conditional expressions*:
if ( ( i > 0 ? ( if ( x(i) > 0.0 ) ? .true. : .false. ) : .false. ) ) print *, "i, x(i) = ", i , x(i)
..
One wonders, if they wanted to add something redundant to the language
to save typing a few extra characters, why didn't just add the above fortran-like statement rather than incorporate the C-like syntax? Was
there any discussion about allowing the chained if statements? ..
if ( ( i > 0 ? ( if ( x(i) > 0.0 ) ? .true. : .false. ) : .false. ) ) print *, "i, x(i) = ", i , x(i)
One wonders, if they wanted to add something redundant to the language
to save typing a few extra characters, why didn't just add the above fortran-like statement rather than incorporate the C-like syntax? Was
there any discussion about allowing the chained if statements?
..
My understanding is starting Fortran 202X, the following will be conforming code based on the new feature introduction of *conditional expressions*:
if ( ( i > 0 ? ( if ( x(i) > 0.0 ) ? .true. : .false. ) : .false. ) ) print *, "i, x(i) = ", i , x(i)
...
I have wondered why certain statements are not allowed after the test
in the Fortran one-line if statement. Often I want to write something like
if (i > 0) if (x(i) > 0.0) print*,"i, x(i)=",i,x(i)
Apologies, I made an error by including an `IF` in the inner expression.
...
By the way, I do not think the brackets around the inner expression are needed per the BNF in the standard, that is the following should work as well:
if ( i > 0 ? x(i) > 0.0 ? .true. : .false. : .false. ) print *, "i, x(i) = ", i , x(i)
...
I also wonder if the evaluation order in this code is undefined:
$ cat all.f90 && gfc all.f90 && ./a.out
real :: x(10)
integer :: i
if ( all([i>0,x(i)>0])) print*,"i, x(i)=",i,x(i)
end
$
On 03/06/2022 09:30, Ev. Drikos wrote:
...
I also wonder if the evaluation order in this code is undefined:
$ cat all.f90 && gfc all.f90 && ./a.out
real :: x(10)
integer :: i
if ( all([i>0,x(i)>0])) print*,"i, x(i)=",i,x(i)
end
$
Ok, this code is likely garbage as it crashed ie with:
integer :: i = -99999999
On Thursday, June 2, 2022 at 8:03:17 PM UTC-4, Ron Shepard wrote:
..
One wonders, if they wanted to add something redundant to the language
to save typing a few extra characters, why didn't just add the above
fortran-like statement rather than incorporate the C-like syntax? Was
there any discussion about allowing the chained if statements? ..
Anyone wondering can read a previous thread at this forum on this, especially the comments by @Steve Lionel who can provide the best commentary on the discussions:
https://groups.google.com/g/comp.lang.fortran/c/q8UaefqOFpc/m/V2m-eji0AQAJ
On Thursday, June 2, 2022 at 5:03:17 PM UTC-7, Ron Shepard wrote:
(snip, someone wrote)
if ( ( i > 0 ? ( if ( x(i) > 0.0 ) ? .true. : .false. ) : .false. ) ) print *, "i, x(i) = ", i , x(i)
One wonders, if they wanted to add something redundant to the language
to save typing a few extra characters, why didn't just add the above
fortran-like statement rather than incorporate the C-like syntax? Was
there any discussion about allowing the chained if statements?
Well, for one, chained IF only works for the .AND. operation.
Also, as well as I know it, the above could be written:
if ( i > 0 ? ( x(i) > 0.0 ) : .false. ) print *, "i, x(i) = ", i , x(i)
That is, the inner conditional operator isn't needed.
Well, for one, chained IF only works for the .AND. operation.
I'm not sure I follow this. In an if statement, any logical expression
can be used. In the short-circuit evaluation context, it would just keep evaluating the expressions until a .false. is generated, and then it
would stop.
On Thursday, June 2, 2022 at 10:36:48 PM UTC-7, FortranFan wrote:
(snip)
Apologies, I made an error by including an `IF` in the inner expression.Some years ago I used an ALGOL system that used IF THEN ELSE for
its conditional operator:
X:= IF A>B THEN A ELSE B;
I think I like the C notation, but others might like that one..
I suspect it would cause problems in fixed form
where blanks
(or lack of) are not significant. IF, THEN, and ELSE are
already reserved words in ALGOL.
On Friday, June 3, 2022 at 7:52:40 AM UTC-7, Ron Shepard wrote:[...]
You can convert:
if(A .OR. B .OR. C) ...
to
if(A) ...
if(B) ...
if(C) ...
at least when the ... is a GOTO, or some assignments.
On 6/3/22 2:39 PM, gah4 wrote:
On Friday, June 3, 2022 at 7:52:40 AM UTC-7, Ron Shepard wrote:[...]
You can convert:
if(A .OR. B .OR. C) ...
to
if(A) ...
if(B) ...
if(C) ...
at least when the ... is a GOTO, or some assignments.The ?:: notation does not address this either, right? For this,
something like a short-circuiting OR is required that forces the
compiler to evaluate the expressions in left-to-right order with no precomputation or out-of-order evaluation allowed. A short circuiting
ANY() operator with those same restrictions would also work.
However, the idea that the result of ?:: is modifiable is a new kind of expression in fortran. None of these other possibilities would naturally
have that feature.
$.02 -Ron Shepard
Anything that can be done with short-circuit logical operators can
also be done using conditional expressions. The expression
A .OR. B .OR. C
where the .OR. operators are short-circuit operators is equivalent to
( A ? .TRUE. : ( B ? .TRUE. : C ) )
Left-to-right order is forced. No precomputation or out-of-order
execution is allowed.
On Saturday, June 4, 2022 at 8:01:48 AM UTC-7, Robert Corbett wrote:
(snip)
Anything that can be done with short-circuit logical operators can
also be done using conditional expressions. The expression
A .OR. B .OR. C
where the .OR. operators are short-circuit operators is equivalent to
( A ? .TRUE. : ( B ? .TRUE. : C ) )Yes. But it is still ugly.
I suspect that there is desire not to change the old logical operators,
but there could be new ones.
Conditional expressions are nice and useful in many places.
Looking at that one, I have no idea what optimizing compilers
will do with it. I am pretty sure that for logical IF, compilers
rarely evaluate the logical expression (that is, store a .TRUE.
or .FALSE. somewhere). I would be less sure in this case.
Left-to-right order is forced. No precomputation or out-of-orderBut that doesn't mean that we can't have new operators
execution is allowed.
that look nicer, and are easier to read.
On 6/4/2022 2:59 PM, gah4 wrote:
On Saturday, June 4, 2022 at 8:01:48 AM UTC-7, Robert Corbett wrote:
(snip)
Anything that can be done with short-circuit logical operators can
also be done using conditional expressions. The expression
A .OR. B .OR. C
where the .OR. operators are short-circuit operators is
equivalent to
( A ? .TRUE. : ( B ? .TRUE. : C ) )Yes. But it is still ugly.
I suspect that there is desire not to change the old logical
operators, but there could be new ones.
Conditional expressions are nice and useful in many places.
Looking at that one, I have no idea what optimizing compilers
will do with it. I am pretty sure that for logical IF, compilers
rarely evaluate the logical expression (that is, store a .TRUE.
or .FALSE. somewhere). I would be less sure in this case.
Left-to-right order is forced. No precomputation or out-of-order execution is allowed.But that doesn't mean that we can't have new operators
that look nicer, and are easier to read.
I agree.
Fortran could borrow "conditional" operators from Burroughs/Unisys
ALGOL:
"a .CAND. b" will not evaluate b if a is false, and "a. COR. b" will
not evaluate b if a is true.
Louis
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 131 |
| Nodes: | 8 (1 / 7) |
| Uptime: | 35:55:12 |
| Calls: | 2,699 |
| Calls today: | 2 |
| Files: | 9,260 |
| Messages: | 2,268,277 |