 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
DanRRight
Joined: 10 Mar 2008
Posts: 2927
Location: South Pole, Antarctica
|
 Posted: Mon Aug 08, 2022 10:13 am Post subject: |
 |
|
Mecej4
Adding content to the file still gives the error | Code: | | *** Unexpected character found after #define |
|
|
| Back to top |
|
 |
mecej4
Joined: 31 Oct 2006
Posts: 1899
|
| Posted: Mon Aug 08, 2022 10:24 am Post subject: |
|
|
Dan, I already noted that FTN95 is attempting to parse #define lines that are not needed in the Fortran file that includes the .h file, even when the macro being parsed is not invoked. Paul has pointed out that FTN95's preprocessing repertoire is not the same as that of typical C compilers.
FTN95 is in many ways not suitable as a replacement for GNU compilers when you are building a large Linux/Unix codebase on Windows. Its command line capabilities are not as extensive as those of other compilers -- you cannot issue a command similar to
| Code: | | gfortran a.f90 b.f90 -Lmydir -llib1 -llib2 -o myprog |
Partly as a result of this difference, you cannot use makefiles from elsewhere (such as Linux) without making substantial adaptations. |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2927
Location: South Pole, Antarctica
|
| Posted: Mon Aug 08, 2022 6:37 pm Post subject: |
|
|
It is one story when one compiler can do some things while the other can do the other things first one can't. Its up to developers to chose at what degree to support C-style or graphics integration or NET or Wininet etcetcetc in their compiler. Some compilers even can do some things absolutely no any other compilers do.
But it is different story when all 5 or 6 other existing Fortran compilers can do some things practically forming the de-facto standard even it is not in the written Fortran Standard while your own compiler is the only which can't do them. Specifically if the trends are pointing into specific directions like better C/C++ integration or multiprocessing, then for the lagging compiler there simply is no other way but to catch and start to support things where others already aligned. Not catching the cohort will marginalize the users base.
As to MAKE utility I have two Linux large codes and one for Windows which use MAKE for compilation. Make typically support whole bunch of compilers. The only compiler which did not work in all cases with MAKE was FTN95. Anyone wants to try? That are not my own codes |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8217
Location: Salford, UK
|
| Posted: Tue Aug 09, 2022 7:44 am Post subject: |
|
|
| NORM2 and the "cast" to REAL in an array constructor have now been implemented for the next release of FTN95 and the DLLs. |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2927
Location: South Pole, Antarctica
|
| Posted: Thu Aug 11, 2022 10:45 pm Post subject: |
|
|
Thanks, Paul.
Here is more work for you extracted from the codes of crazy Fortran youngsters who surprisingly embraced so many modern Fortran latest tricks that the codes look unreadable as if this is not a Fortran. I lost last 4-5 months deciphering them. And unfortunately they are not in our forums but in the forums for the other compilers. This time it is a demo for "associate" :
| Code: | program associateTest
implicit none
integer :: a=1,b=1
associate( x => a*b )
print *, x ! yields: 1
a=10
print *, x ! yields: 1
end associate
associate( x => a )
print *, x ! yields: 10
a=100
print *, x ! yields: 100
end associate
end program associateTest |
|
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8217
Location: Salford, UK
|
| Posted: Fri Aug 12, 2022 7:19 am Post subject: |
|
|
| Thanks. I will add ASSOCIATE to the list. |
|
| Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012
Posts: 818
Location: Lanarkshire, Scotland.
|
| Posted: Fri Aug 12, 2022 12:22 pm Post subject: |
|
|
I have seen Dan's example for the use of ASSOCIATE before, and find it very confusing. Why does the second print*, x statement return 1 and not 10 since the value of a is updated in the proceeding line?
The final print*, x statement does appear to recognize that a has been updated within the second associate block. What is the difference here - that I cannot see? |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8217
Location: Salford, UK
|
| Posted: Fri Aug 12, 2022 1:35 pm Post subject: |
|
|
Ken
I appears that expressions are stored as the constant that they evaluate to (at the point of association), whilst simple variables are treated as targets to the identifier on the LHS which is effectively a pointer.
In the latter case you effectively get a pointer to a variable target with the pointer having a limited scope. |
|
| Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012
Posts: 818
Location: Lanarkshire, Scotland.
|
| Posted: Fri Aug 12, 2022 8:38 pm Post subject: |
|
|
Thank you, Paul, I can see that now.
A rather artificial test program to try sometime:
| Code: | program test
implicit none
integer, parameter ::dp=kind(1.d0)
integer j
print*, 'j [i.e. sqrt(-1)] raised to powers 1, 2, 3, and 4'
do j = 1, 4, 1
associate( j => cmplx(0.d0,1.d0,kind=dp)**j )
print*, j
end associate
end do
end program test |
|
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2927
Location: South Pole, Antarctica
|
| Posted: Tue Aug 23, 2022 2:32 am Post subject: |
|
|
More twists from Fortran language nazis.
1) Found such pieces in their codes | Code: | call af_particles_to_grid(tree, i_pos_ion, n_photons, &
get_id, get_rw, interpolation_order_to_density, &
iv_tmp=i_tmp_dens, offset_particles=n_part_before)
|
and made simple demo test | Code: | Program test
Real a, b
b=1
Call sub1 (a=b)
end program
subroutine sub1(A)
Print*,A
End subroutine |
which gives the following error report
| Code: | | *** SUB1 has an implicit interface and cannot have keyword arguments (possible |
Is this useful modern Fortran feature or just an usual perversion which makes code unreadable and often just plain slower?
2) What for IMPORT is used here?
| Code: | interface
!> Function that returns a scalar
real(dp) function box_func(box)
import
type(box_t), intent(in) :: box
end function box_func
!> Reduction method (e.g., min, max, sum)
real(dp) function reduction(a, b)
import
real(dp), intent(in) :: a, b
end function reduction
end interface |
Is it supported by FTN95 ? |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8217
Location: Salford, UK
|
| Posted: Tue Aug 23, 2022 9:00 am Post subject: |
|
|
1) The error report in the simple demo test is correct. An explicit interface is required in this context.
2) IMPORT is supported but it is a recent addition. Please report any failures. |
|
| Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012
Posts: 818
Location: Lanarkshire, Scotland.
|
| Posted: Tue Aug 23, 2022 9:29 am Post subject: |
|
|
Dan,
SUB1 is not an internal routine i.e. contained in the program or a module. As it is an external routine it must be listed in an interface block.
So there are four ways to make this code work:
Add an interface block:
| Code: | Program test
Real a, b
interface
subroutine sub1(A)
real A
end subroutine sub1
end interface
b=1
Call sub1 (a=b)
end program
subroutine sub1(A)
Print*,A
return
End subroutine |
Move SUB1 to a new CONTAINS section in the main program
| Code: | Program test
Real a, b
b=1
Call sub1 (a=b)
contains
subroutine sub1(A)
Print*,A
End subroutine
end program |
Put everything in a module
| Code: | module demo
contains
subroutine test
Real a, b
b=1
Call sub1 (a=b)
end subroutine test
subroutine sub1(A)
Print*,A
End subroutine
end module demo
program p
use demo
call test
end program p
|
Put SUB1 in a module and USE the module in the main program:
| Code: | module demo
contains
subroutine sub1(A)
Print*,A
End subroutine
end module demo
program test
use demo
Real a, b
b=1
Call sub1 (a=b)
end program test
|
|
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2927
Location: South Pole, Antarctica
|
| Posted: Tue Aug 23, 2022 7:33 pm Post subject: |
|
|
Paul, Ken,
Thanks but my question was about rationale of doing this unusual and hence confusing thing.
Why not do this obvious way which will not require any trickery with modules, interfaces which are just causing the code to be bloated and less readable?
| Code: | Program test
Real a, b
b=1
a=b
Call sub1 (a)
end program
subroutine sub1(A)
Print*,A
End subroutine |
Or this error was because Fortran does not check subroutine arguments when it is called on types consistency so that the code does not know if A and B are functions or regular variables? If people think that the ability to call sub1(a=b) is an useful addition to Fortran (to make crazy nazis happy or just as a copycats because some other compilers do that why not Fortran?) why not to make compiler to check a and b and in my case allow it go without any interfaces ? Sorry, i might sound dumb, because still for more than a month deciphering one code written as claimed in Fortran 2011 which is like a cryptomachine causing my brain damage  . It outputs data in proprietary format SILO for which there is no file converters or viewers for its structure (i can see its visualization content in third part graphics software though, but this is not enough for futher use of code output) |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8217
Location: Salford, UK
|
| Posted: Wed Aug 24, 2022 8:36 am Post subject: |
|
|
Dan
Optional and named/keyword arguments were introduced at the "beginning" i.e. in the Fortran 90 standard. |
|
| Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005
Posts: 2403
Location: Yateley, Hants, UK
|
| Posted: Wed Aug 24, 2022 3:39 pm Post subject: |
|
|
Hi Paul,
For some of us, Fortran 90 was more like the end than the beginning ...
Eddie |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
