What is the difference between the INTERFACE block and the MODULE procedure in fortran?

Question

I'm a little confused about using an interface block inside a module and using the CONTAINS operator to create an “explicit interface” for a procedure inside a module.

Usually I write a procedure using an interface block inside a module. For instance,

MODULE ModExample INTERFACE SUBROUTINE Sumatory(a, b, c) IMPLICIT NONE INTEGER, INTENT(IN)::a INTEGER, INTENT(OUT)::b INTEGER, INTENT(OUT)::c END SUBROUTINE Sumatory END INTERFACE END MODULE ModExample SUBROUTINE Sumatory(a, b, c) IMPLICIT NONE INTEGER, INTENT(IN)::a INTEGER, INTENT(OUT)::b INTEGER, INTENT(OUT)::c !Executable statements here END SUBROUTINE Sumatory 

And it works for me. But it can also be written using the CONTAINS stament inside the module, and this is actually the way the example procedures are written in Fortran books that I consulted with.

 MODULE ModExample CONTAINS SUBROUTINE Sumatory(a, b, c) IMPLICIT NONE INTEGER, INTENT(IN)::a INTEGER, INTENT(OUT)::b INTEGER, INTENT(OUT)::c !Executable statements here END SUBROUTINE Sumatory END MODOULE ModExample 

So what happened to the INTERFCE block? Are both equivalent constructions? Which of the two aploas should I use? Perhaps all these questions can be answered with a big "it depends", but I would like you to give an explanation of their differences. Thanks in advance.

Answer 1

It depends, but if you have no good reason for the opposite, use the module procedures ("after the content").

What is “wrong” with the first approach is that you had to specify the procedure interface twice - once in the interface block and once in the procedure definition itself. In the second case, the interface is specified only once - in the procedure definition. The need to maintain multiple specifications is a potential source of errors.

developed:

In the first code example, the source between the last SUBROUTINE and END SUBROUTINE statements (not inside the interface block) is what is called an external routine. This is a standalone software unit. An external routine defines an external routine.

In the second code example, the source between the SUBROUTINE and END SUBROUTINE statements that appears after the CONTAINS statement in the module is the module subroutine. This is part of a module module. This module routine defines the module procedure.

("Subroutine" refers to the construction of the source code, and the procedure refers to what defines the source code.)

There are also internal routines (they appear after the CONTAINS statement inside the main or modular subsystem of the host or main program) that define internal procedures and individual module routines, which are another way of defining module procedures.

Fortran software modules (main programs, modules, submodules, external routines, block data) use a separate compilation model. When compiling a specific program module, the compiler acts as if it did not pay attention to any other program block in the program, the opposite is true in the explicit specification of the bar in the source.

One of the consequences of this is that if you refer to an external procedure in scope without explicitly telling the compiler what this external procedure looks like, then the compiler must implicitly deduce the interface for the external procedure from the link method (the procedure has an implicit interface). The procedures referenced in this way cannot use many of the new possibilities of passing arguments to the language (because the compiler does not know how to call and pass arguments to the procedure correctly). In practice, compilers are also much less likely to identify errors, such as inconsistent argument types.

An interface unit, such as the one in the first code example, can be used to explicitly specify the interface of an external procedure. References to an external procedure in the source code where this explicit interface is available can use all modern argument passing functions and will probably significantly improve detection of compiler errors. However, the programmer still has to make sure that the corresponding characteristics of the interface body and the actual definition of the external procedure are consistent.

The language also has a requirement that only one interface available for a procedure is available in the scope block. Inside the external routine that defines it, the interface for the procedure is already clear, so the programmer must ensure that the body of the interface for the same external procedure is not accessible inside the external procedure.

One of the explicit specifications that allows sharing information between program units is the USE statement, which gives information about things defined by the module that are available in the area in which the USE statement appears. This includes knowledge of the procedures defined or declared by the module.

(The language requires that the source for the common parts of the module is "available" before the module has been used, which actually means that the source code of the module must be compiled before the USE statement for the module is compiled.)

Unlike external procedures, the interface for a module procedure or internal procedure is always obvious in the area where its identifier is available - there is no need to have an interface body for a module or internal procedure (separate modules of subprograms aside, you should not have an interface body).

In short:

The first example - you have a module with an interface body for an external procedure, and then the external procedure itself. You can reference this external procedure without using the USE module, in which case an implicit interface is used (limited capabilities, error prone). Alternatively, if the USE'd module is in the reference area, the interface will be explicit. In this case, the programmer must make sure that the interface of the interface and the external definition of the procedure match, and the body of the interface for the external procedure is not available in the external procedure. This is a bug vulnerability and inconvenience in maintenance.

The second example - you have a module with a module procedure. You cannot refer to a module procedure through your name without using the corresponding module. The interface for such a link will always be explicit. There is no need to maintain a separate interface for the procedure.

The only good reason for us, the first form over the second form is if you need to break the compilation dependency loop or otherwise limit the long chain of compilation dependencies.