forums.silverfrost.com

DanRRight · Posted: Mon Nov 16, 2015 8:42 pm Post subject: Why this is not an error ?

I think i asked that question before...

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

Dan,

I am not sure what your error is ?
I compiled the following file (named dan.for) using ftn95 dan.for /-imp /lis /xref and got the following response:

DanRRight · Posted: Tue Nov 17, 2015 10:11 pm Post subject:

To show the example the comma at the end of the line was intentionally missing. As a result of forgotten comma, instead of two variables ccccccccccccc and dddddddddd, the new variable is created cccccccccccccdddddddddddd

The point was that this kind of line continuation when the name
starts on one line and is continued on another should not be permitted
because this is most stupid idea - to break the variable names such way.
(for example because if you will search for this two line variable in editor you will not find it. Also in human syntax we use '-' sign to indicate that the word is continued on the next line. Fortran should follow this to be closer to natural language rules to reduce potential errors. Such errors are rear of course but in the large code the chance to have it increases which may break the entire code).

This way of continuation is error prone if you do not use "implicit none".

My experience says that i often miss comma specifically when in the hurry which is my regular state. Such errors sometimes not easy to find.

This is an addition to the discussion which ended with very handy option NO_TRUNCATE which treats now similar error when the variable hits 72-character limit and the new variable is created as a sum of two lines.

Interesting if someone here uses this way of continuation of variable names. If no one do that then we should do something with it. May be offer additional switch to guard codes from potential errors.

LitusSaxonicum · Posted: Wed Nov 18, 2015 11:09 am Post subject:

Dan,

While what you describe looks like lunacy to me, but my guess is that it is standard-conforming. I think if you looked at some source codes from the 60s and 70s you might find examples there, as you needed to think well ahead when using a card punch! (Although they would be only a few characters on each line).

If it wasn't in COMMON, FTN95 would tell you it was defined but not used. Don't you cut'n'paste COMMON or put it in an INCLUDE?

Are you now a convert to IMPLICIT NONE? I feel like I lost my last friend in the whole world!

Eddie

DanRRight · Posted: Wed Nov 18, 2015 5:02 pm Post subject:

No i did not convert to implicit none.

My point and wishes here were to make Fortran
more bullet proof and future proof.
We got a lot of knowledge since punchcard Fortran.
If i print my code on punchcards the pile would
be 50 meters high. Just reading this would cause
many input errors. If we'd still use punchcards such
codes like mine would be impossible, they'd die
under entropy of own faults.

So i am trying to extend the life of my code beyond
that, beyond future 1 Million lines when i combine
my 32bit codes into one 64bit one and still get it
manageable. That implies attention to small details
in syntax, in depth of diagnostics, in quality of compiler
implementation etc...64bitness is also part of futureproof.

Fortran must be not only fast and naturally simple
but also reliable to make a heartbeat controllers in it.

I feel that if i'd chose any other compiler then this one
i'd stop my massive code development long ago. And if
it became 64bit 10 years ago, then it would be a
Godzilla among Fortran codes by now. And if 20 years ago
Salford developed the compiler for supercomputers as i
asked them at that time (having access to all 5 "top5"
supercomputers in the world at the same time) the
only my code wouldn't do is dishwashing Smile