fpt Reference: Deprecated Constructs

fpt and WinFPT Reference Manual - Command-line Commands

| SimCon Home | Ref Manual Home |

Deprecated Constructs

The Issue

fpt issues warnings for dangerous and sometimes non-standard features in the code. For example, Fortran keywords used for variable names, duplicate sub-programs and non-standard string delimiters. Please see fpt warnings for the complete list.

In addition some users have asked that fpt should issue warnings for constructs which are legal and correct Fortran but which they deprecate. These are discussed below.

GOTO Statements

There is a wealth of literature describing the pitfalls and dangers of GOTO statements. fpt will not remove GOTO statements. Users are recommended to use PlusFort from https:fortran.uk to do this.

However, there are at least three cases where GOTO statements should be used.

In handling exceptions. A GOTO statement is a convenient way to terminate processing and exit from deeply nested code to a specified location.
In handling case collectors where there are multiple routes from a case-like construct (which is not necessarily written with a SELECT CASE statement).
In computed GOTO statements. Often SELECT CASE constructs are compiled to generate the same code as IF-THEN-ELSE chains. The result is that the machine makes, on average, half the number of comparisons as the number of CASE clauses. This can be very inefficient. If the CASE selectors are a contiguous set of integers a computed GOTO will be very nuch more efficient.

A simple example of a computed GOTO from the lexical analyser of fpt is shown in a computed GOTO example. Some of the computed GOTO switches in fpt have hundreds of clauses.

DATA Statements

The argument is that DATA statements can be replaced by data specifications in the declaration statements of the variables concerned. For most scalar variables this is often a good idea. It is better if all of the attributes of an object are specified in one place.

There are two situations where DATA statements may be a better solution.

Where only part of an array is to be initialised. For example, in fpt itself, the beginning of the dictionary is initialsed with the Fortran keywords and intrinsic function names. The remainder is not initialised.
In machine-generated code where an array declaration is within a module, but the data initialisation is in an INCLUDE file. In Fortran INCLUDE is a statement and cannot therefore occur within another declaration statement. (You could always use #include).

COMMON Blocks

COMMON blocks are almost obsolete. The authors have encountered only one case where they could not be replaced by modules. This is a large power distribution suite of over 100 programs which communcate through shared memory both with each other and with a C program. The communication areas are implemented as COMMON blocks pinned to known memory locations by !DEC$ psect directives.Some of these COMMON blocks are very large. There is probably no other way to do this.

Data Only Modules

It has been suggested that variables should always be declared in association with the sub-programs which reference them. This is generally a good idea. A common exception is the use of a module for the kinds of numeric objects. A small module which specifies the kinds will be used almost everywhere.

Sub-programs Outside Modules

The advantage of requiring subroutines and functions to be written within modules is that the interfaces are always visible to the routines which call them. This will prevent many possible errors.

The disadvantages are that when routines are placed in libraries the .mod files must be made available when compiling the callers, and that the use of modules may lengthen the time taken to build the codes.

Derived Types Outside Modules

When objects of derived types are passed as arguments or occur as function results visible to multiple sub-programs it is clearly a good idea to declare the types in modules. However there seems little point in creating modules for derived types used only in single routines.

Pre-defined Logical Units

The authors have seen many occasions where the same logical unit was accidentally used for two different files. There are two defences against this issue.

To require that all files are opened with the NEWUNIT construct. This will prevent collisions. This was the intent of the request for this warning.
To define all of the required logical units in a single module which is used in all routines with file I/O. The advantage is that if an I/O error occurs it is easy to see which file is involved.