forums.silverfrost.com

DanRRight · Posted: Fri Jun 24, 2022 9:51 pm Post subject:

Simon,
Wow, i did not know about preprocessor is already there. Never used or seen people used it in this forum at least.

As to these new Fortran features there clearly are world champions of obscurity and verbosity. Out of curiosity i compared the original code written by other people which was then rewritten into Fortran2003 code. Original was ~3 times smaller and absolutely clear. No heavy use of derived types, pointers, interfaces, model procedures, no anything fancy complicating readabilty to the state you're totally lost. For example, in Fortran2003 code IF or DO blocks look very small. But the trick is that this was because the source text was packed into subroutines. These subroutines immediately called another subroutines, which called another and another which called INCLUDE files Smile

Fun was to find that OPEN(file=..., status=...) is not just one line of Fortran code but also a subroutine 113 lines long. The WRITE(unit=..., Format=...) not one line of Fortran code but several subroutines around 2KB each which are very specific for some obscure data packing file format no one here used or knew.

One of the most confusing is that you never know the variable is array or not and what is its dimensions, types and interfaces, and how to find all that quickly. And when trying to find all that among 100s of files you totally lose the track.

Will i change my mind as times go and i will use these features? Possible but not very likely. Because even the authors of this long rewritten code now say that the code is quite large and complex Smile

Additional intrigue with this code is that the original Fortran source code was also rewritten by some other people. Fun is that it was moved to C. Will ask these folks if they are happy with that move too in which i doubt a lot. I have seen people moved from Fortran to C and then the code development almost stopped. Soon i will be able to compare several such codes performances, and we will see how much they no doubt lost here too.

DanRRight · Posted: Wed Jul 13, 2022 7:24 pm Post subject:

Simon,
i tried this code

PaulLaidler · Posted: Wed Jul 13, 2022 8:38 pm Post subject:

You need /CFPP.

https://silverfrost.com/ftn95-help/options/using_the_preprocessor.aspx

DanRRight · Posted: Thu Jul 14, 2022 6:16 pm Post subject:

Thanks, Paul

DanRRight · Posted: Sat Aug 06, 2022 8:13 am Post subject:

About preprocessor: in some 3rd party code FTN95 found the error on this line

LitusSaxonicum · Posted: Sat Aug 06, 2022 11:52 am Post subject:

Referring to John Campbell's post on 22nd June, I also find REAL*4 of very little use. Having grown up using computers that had a sensible default REAL size (2 x 24-bit words), with INTEGERs the same size, I do find:

OPTIONS (INTL, DREAL)

suits me fine, even though the length of INTEGER is only half that of REAL. It's a shame that there is no equivalent to INTL for INTEGER*8.

I suspect that there may well be a use for short INTEGERs somewhere (for example, for grey codes where after all we only need to cope with 0 or 1), for me even the 32-bit address space is unimaginably vast, and the waste of space with all those unused bits doesn't matter.

As to some of the other innovations in this and the posts on Fortran 2003 and 2008 features, can someone please remind me of the Star Trek episode where Spock leans over to Kirk, and says "Its FORTRAN, Jim, but not as we know it"?

PaulLaidler · Posted: Sat Aug 06, 2022 1:20 pm Post subject:

Dan

/CFPP is required for #include etc.

#include works on its own without a VPARAM.

For #if NDIM == 2 you could use...

/CFPP /DEFINE NDIM 2

then the #if block will be compiled.