Question on Modules and Interfaces

[DavidWhite]

When defining routines and their interfaces in modules, is this correct, or do I need a separate module for the interfaces?

MODULE MyMod
INTERFACE
SUBROUTINE MySub
...
END SUBROUTINE MySub
END INTERFACE
CONTAINS
SUBROUTINE MySub
...
END SUBROUTINE MySub
END MODULE MyMod

The aim is to then be able to make MySub accessible in a number of projects simply using USE MyMod.

Thanks,


David

[IanH]

The MySub module procedure (a procedure that appears after the contains statement in a module) gets an explicit interface (and all the features that go with that) inside the module and in procedures that use the module "automatically", as an inherent part of being a module procedure. Because this happens automatically, you don't need to provide an interface and it is actually an error to do so (conceptually there would then be two interfaces for the one procedure). The compiler should complain about your example.

To achieve your aim just delete the statements from INTERFACE to END INTERFACE inclusive and place the use statement in the procedures that will call MySub.


If MySub was not a module procedure (it was defined by a subroutine subprogram that did not appear after the contains statement in a module), then you could manually provide an explicit interface in a module, as you have done. Other program units that used that module would then have access to the interface for MySub and all the features that explicit interfaces (argument checking/assumed shape/extended trading hours) bring (i.e. the features that module procedures get automatically with less typing and chance of error).


(Beyond language aspects - the other projects will need to be able to access the mod and obj files output by the compiler when compiling the module).

[Steven_L_Intel1]

Ian is correct. The language prohibits having visible an interface to yourself. There was a proposal to relax this for F2008 but it got turned down, though the case described in David's post wouls still be disallowed. The problem is that an INTERFACE block always defines an "external procedure" which is inconsistent with a module or contained procedure.

Where interface-to-self could be useful is when updating old F77-style applications where all procedures are external. You might want to declare interfaces for all of these procedures, put those in a module and then USE it to enhance error checking. For example:

[fortran]MODULE MyMod
INTERFACE
    SUBROUTINE MySub
    !...
    END SUBROUTINE MySub
END INTERFACE
END MODULE MyMod

SUBROUTINE MySub
USE MyMod
!...
END SUBROUTINE MySub
[/fortran]

Intel Fortran does allow this as an extension, though I note when I try it that if I ask for standards warnings, the message doesn't say it is an extension.

[mecej4]

In the context of updating F77 code, being able to check interfaces-to-self can be very useful. Often, one uses a utility (such as Polyhedron's PlusFort) to convert F77 code to F90, generating as a byproduct interfaces to the subprograms, and at one's request having USE statements inserted into the converted code.

Although Intel Fortran accepts such interfaces as an extension, the usefulness of the extension is lessened by an apparent inability to check for consistency between the declarations in the interfaces and the declarations in the implementations.

For example: with the interface in intf.f90 as

[fortran]MODULE MyMod
INTERFACE
    SUBROUTINE MySub(a,b)
      integer,intent(in) :: a
      real, intent(out) :: b
    END SUBROUTINE MySub
END INTERFACE
END MODULE MyMod
[/fortran]

and the implementation and usage in prog.f90 as

[fortran]SUBROUTINE MySub(p,q)
USE MyMod
   integer, intent(out) :: p
   integer, intent(out) :: q
   p = 4
   q = 6
   return
END SUBROUTINE MySub

Program MyProg
USE MyMod
   integer :: i
   real    :: x
   call Mysub(i,x)
   write(*,*)i,x
End Program MyProg
[/fortran]

Compiled with

[bash]$ ifort  -warn all -check all intf.f90 prog.f90
[/bash]

the errors as to type and intent are not caught -- perhaps there is a combination of compiler switches that would make this work, but I have not discovered it yet.

[TimP]

When compiled in a single file, the xml report for diag-enable:sc shows

m4.f90(22): error #12040: actual argument 2 in call to "
;MYSUB" doesn't conform to formal argument. See (file:m4.f90 line:9)sc_verbose>

Apparently, that's a report of the real vs. integer conflict.

It does look a little better in an xml viewer, but I don't know how to capture the clean view, other than by screen shot.

[mecej4]

It's good to have -diag-enable sc available. Having only XML output and not text output is a nuisance unless the project is large and XML tools are available to take advantage of the structure of the diagnostic output.

However, I don't think that the checking goes far enough, and I hesitate to trust compiler options that do not deliver on the suggested promise (such as all those options that have meaningful names but do nothing other than suppressing error messages from obsolete makefiles).

In my example, if all instances of REAL are replaced by INTEGER, the source checker gives no messages. The program runs, as well, and the inconsistency between interface and implementation remains undetected.

[Steven_L_Intel1]

In the current release, you need Intel Inspector XE to view the source checker messages in a "nice" way.

The compiler actually can compare interface blocks to the routine when /warn:interface is in effect. This will partly depend on order of compilation. I do admit to being puzzled by the current behavior and will take a look at that.