Tree TromboneOfMassDestruction

Navigation ...


Scientific Writing ...


Other Writing ...


Reference details

Author(s) Year Title Reference View/Download

Les Hatton


Fortran, C or C++ for geophysical development

Journal of Seismic Exploration, 1(1)JSX_0192.pdf

Synopsis and invited feedback

This work was or is being reviewed by domain-specific experts appointed independently.

If you would like to provide feedback just e-mail me here.

Synopsis Invited Feedback Importance (/10, author rated :-) )
Compares these three languages and their suitability for geophysical software development. Contains an empirical safer subset for Fortran 77. Note that the international standard for C++ is a gigantic 789 pages and can deflect light in its gravitational field. Buy yours today.All my work was done for Fortran 77. Significant things have happened to Fortran since 1990. Van Snyder (21-Jun-2001, 7-Mar-2005) contributed this important feedback with respect to Fortran 90, 95 and 2003:-

ASSIGN, assigned GO TO and assigned format are deleted from Fortran 95. (1.40) Non-integer DO variables are deleted from Fortran 95. (1.26) The PAUSE statement is deleted from Fortran 95. (1.36) The H edit descriptor is deleted from Fortran 95. (1.6)

Most compilers have options to announce unreachable code, unreferenced labels, declared but not used variables, and referenced but not defined variables. Encourage use of those options. Encourage use of tools that detect such things in case ones compiler doesn't.

Recommend in (1.6) to use character variables instead.

Most of the problems you mention with respect to calling sequences (e.g.1.10,1.22, 2.10) are solved by using explicit interfaces (introduced in Fortran 90). Module procedures (introduced in Fortran 90) always have explicit interface. Their use should be preferred to external procedures. Where external procedures are used, it is good practice to specify an explicit interface instead of using an EXTERNAL statement or (worse yet) no declaration at all. This is not, however, always possible. A particularly difficult case is in interfacing to C functions that expect a "void*" argument, and deduce the type of it from the run-time (!) values of other arguments. I hope you caution against doing such things in your "Safer C" book. [Ed .. I didn't cover cross-language calling because it is usually implementation-defined at best and usually fraught with danger.]

Instead of simply recommending not to use REAL R(1) (1.13), point out that a last-dimension specification of "*" for dummy arguments is provided in Fortran 77, with the meaning of "unspecified upper bound." Suggest using assumed shape (bounds given by colons), with the warning that this may sometimes cause copy-in / copy-out argument passing.

In addition to (1.16) recommend always using IMPLICIT NONE, which is standard in Fortran 90. Delete the reference to it being nonstandard in (1.17). Recommend its use instead of IMPLICIT UNDEFINED because the latter is not standard.

Recommend in (1.24) that module variables (introduced in Fortran 90) should be used instead of COMMON.

Recommend use if IACHAR and ACHAR instead of ICHAR and CHAR in (1.39).

Some compilers now offer detection of access to undefined variables, pointers with undefined association status, or pointers with defined association status but that are not associated. Most offer bounds checking for arrays. Recommend the use of these options, at least during development (1.50)

Free-form source prohibits embedding blanks or continuations within identifiers (1.52). Recommend use of free-form source generally.

Fortran 95 specifies that DATA or initialization within a type declaration implies SAVE. There are cases where using DATA is appropriate (2.2); its use should be cautioned rather than prohibited, and the implication of SAVE should be mentioned alongside the caution (i.e., the initialization happens once, not every time the scoping unit is invoked). One example is for a "first time" flag, that indicates certain calculations for which the results are deposited into SAVE variables, e.g. involving the precision of arithmetic, need not be repeated. For objects that have immutable values that the processor can compute, recommend the PARAMETER (named constant) attribute. Fortran 90 allows specification of dummy argument usage intent, in the case that a procedure has an explicit interface. There is not a problem of using a DO index as an actual argument if the corresponding dummy argument has INTENT(IN) (2.3). BTW, your (2.3) should caution against DO loop variables being used as ACTUAL arguments (for which the corresponding dummy arguments do not have INTENT(IN)). There is no problem using a DUMMY argument for a DO index, provided it does not have INTENT(IN).

As for new features of Fortran 90, suggest that ALLOCATABLE be preferred to POINTER. There were some deficiencies of ALLOCATABLE in Fortran 90 and Fortran 95, that lead one to need to use POINTER, but these were remedied by Technical Report 15581, which has been included in Fortran 2003. Point out that TRANSFER may have unexpected performance problems. The interaction of FORALL and WHERE may be difficult to understand; caution against using them together.

Recommend using the new execution constructs of Fortran 90 (SELECT CASE, DO and DO WHILE).


Related links

Related papers and links

Auto-generated: $Revision: 1.63 $, $Date: 2020/01/25 16:18:09 $, Copyright Les Hatton 2001-