View previous topic :: View next topic |
Author |
Message |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2396 Location: Yateley, Hants, UK
|
Posted: Wed Dec 11, 2024 2:20 pm Post subject: No wonder people find it hard to read the instructions ... |
|
|
Looking in FTN95.CHM I found:
/NO_TRUNCATE
Characters beyond column 72 (132 for free format files) are treated as an error.
Surely there's a 'not' missing?
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8089 Location: Salford, UK
|
Posted: Wed Dec 11, 2024 3:43 pm Post subject: |
|
|
Eddie
For fixed format, characters after column 72 are treated as comments.
When /NO_TRUNCATE is applied, such comments are not permitted.
I think that it was something that Dan asked for.
Perhaps the name of the option is misleading. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2396 Location: Yateley, Hants, UK
|
Posted: Wed Dec 11, 2024 5:20 pm Post subject: |
|
|
Paul,
I'm a real oldie, as you probably know, and am completely content with column 72 being the end of useful space. You are probably right that the name is misleading - it certainly seems so to me.
Eddie |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2893 Location: South Pole, Antarctica
|
Posted: Thu Dec 12, 2024 11:36 am Post subject: |
|
|
This option is a must for everyday use, specifically for the older codes where people usually did not use "implicit none". I do not use "implicit none" even for the modern codes. Otherwise you will get a bug in the code and do not know about it sometimes for years |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2396 Location: Yateley, Hants, UK
|
Posted: Thu Dec 12, 2024 11:54 am Post subject: |
|
|
Dan,
The argument is not whether the facility is useful or essential, but whether the implicit meaning of the label and/or the definition of what it does (given in FTN95.CHM), make what it does clear (or not).
Your assertion, that the option is essential, by the way, is contestable.
I find it rather more helpful not to blame errors on the work of Satan manifested through the compiler, when they are more probably human error. Perhaps Paul might be persuaded to add an alternative to /NO_TRUNCATE - I suggest /NO_DEVILRY. But that would still leave the description of its function unclear.
Merry Christmas, and a devilry-free New Year
Eddie |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2893 Location: South Pole, Antarctica
|
Posted: Thu Dec 12, 2024 6:43 pm Post subject: |
|
|
Eddie
Decently i did not understand what you both discussing here and even agreeing that something is missing or needs changes. But i admit my English is too poor, to me this option is clearly named and explained
By he way, speaking about how useful this option is. If you
1) do not use implicit none
2) your codes are larger than ~30k lines
just try to use /no_truncate, it will almost with 100% probability find an error in your code.
I immediately saw a dozen such errors in third party large codes of size 100-300k lines which were made under other compilers which do not have or did not use the major code devilry exterminator /UNDEF or /CHECKMATE. Saw such error even with the code which uses implicit none
I permanently make such 72/132 limit breaking errors when just try to touch my codes or only look at them or pass nearby . |
|
Back to top |
|
|
|