The following is the code skeleton from VASP. My work is that porting it on one new platform. And when I use the compiler of that platform, I got the error. If I comment out the use m and I also get "It must have an explicit interface specified." I just want to make a minimum modification to avoid incurring errors into other parts of the program.
module m
interface
subroutine a
end subroutine
end interface
interface
subroutine b
end subroutine
end interface
end module
subroutine a
use m
call b
end subroutine
In the code as shown, the interface for subroutine a defined in the module is accessible inside subroutine a via use association. Because a subprogram already defines an explicit interface for any procedures that it defines, this means that you have two separately defined explicit interfaces for the same procedure accessible in the same scope. This is a violation of the rules of the language (F2008 12.4.3.2p7).
You can use the ONLY clause on the USE statement to exclude the interface body variant of the subroutines interface from being made accessible by use association inside the subroutine.
module m
interface
subroutine a
end subroutine
end interface
interface
subroutine b
end subroutine
end interface
end module
subroutine a
use m, only: b
call b
end subroutine
Why not simply:
module m
contains
subroutine b
! code
end subroutine b
subroutine a
! code
call subroutine b
end subroutine a
end module m
From what you've posted I don't see any recursion (neither subroutine calls itself, a calls b but b doesn't call a) nor any need for it. Nor do I see a need for explicitly writing interface blocks; package the subroutines into a module and let the compiler take care of checking interface specifications and agreement.
Related
Consider the following code, which defines an abstract type foo with a deferred procedure sub, and a type foo2 which extends foo:
MODULE m
TYPE, ABSTRACT:: foo
CONTAINS
PROCEDURE(sub_int), DEFERRED:: sub
END TYPE
INTERFACE
SUBROUTINE sub_int(THIS, x)
IMPORT:: foo
CLASS(foo), INTENT(IN):: THIS
DOUBLE PRECISION, INTENT(INOUT):: x
END SUBROUTINE
END INTERFACE
TYPE, EXTENDS(foo):: foo2
CONTAINS
PROCEDURE:: sub
END TYPE
INTERFACE
MODULE SUBROUTINE sub(THIS, x)
CLASS(foo2), INTENT(IN):: THIS
DOUBLE PRECISION, INTENT(INOUT):: x
END SUBROUTINE
END INTERFACE
END MODULE
SUBMODULE (m) s
CONTAINS
MODULE PROCEDURE sub
x= x**2
END PROCEDURE
END SUBMODULE
Is there a way to avoid writing the second interface?
I understand that it is needed in order to declare sub as a module procedure (otherwise the implementation would need to be done in the module, and not in the submodule), but is this the only way to do it?
In other words, is it possible to implement the procedure sub for foo2 without rewriting the entire interface for it?
It is not possible. A separate module subprogram requires an interface block, either in its defining submodule or an ancestor of its defining submodule.
Whether a procedure happens to be nominated by one (or more!) bindings of one (or more!) types is totally irrelevant.
I have an object parsing a textfile. Here's my main program:
program main
use Parser_class
implicit none
type(Parser) :: Parser
call Parser%ProcessFile('data.txt')
call Parser%Deallocate
end program main
where the type definition is
module Parser_class
type :: Parser
contains
procedure, public :: ProcessFile
procedure, public :: Deallocate
end type Parser
contains
subroutine ProcessFile(self)
...
end subroutine
subroutine Deallocate(self)
class(Parser) :: self
...
end subroutine
end module Parser_class
I read about the final keyword and altered the type definition to
module Parser_class
type :: Parser
contains
procedure, public :: ProcessFile
final :: Deallocate
end type Parser
contains
subroutine ProcessFile(self)
...
end subroutine
subroutine Deallocate(self)
type(Parser) :: self
...
end subroutine
end module Parser_class
Additionally, in the main program I don't have call Parser%Deallocate anymore. The finalizer doesn't get called now at any time. I somehow get this is because I never destroy or overwrite the Parser object. But how could I do this, or what is the proper way to handle the deallocation process?
In the Fortran 2008 standard, when finalization comes about is given in section 4.5.6.31. I won't copy all the times here, but I will summarize.
What is clearly mentioned following from when, is when not:
If image execution is terminated, either by an error (e.g. an allocation failure) or by execution of a stop-stmt, error-stop-stmt, or end-program-stmt, entities existing immediately prior to termination are not finalized.
This covers your program. Parser is in the program's scope and it still exists at the end of the program. There are no apparent other things which would cause finalization.
If Deallocate is a final procedure for the type, then there are subtle ways in which finalization of an object of that type differ from a call of the type-bound procedure. In finalization, the process is recursive: components and parents are themselves subject to finalization. With a subroutine call that recursion must appear manually in some way.
In many cases one doesn't care that an entity isn't finalized at the end of the program. After all, any deallocation is then the operating system's problem, not the programmer's. However, there are times other forms of tidying up are indeed desirable.
True finalization can be forced in some ways. If the list below is examined, two options come to mind:
make the Parser object allocatable and explicitly deallocate it;
wrap the whole thing in a block construct.
To crudely summarize when finalization happens:
when there's deallocation (pointer or allocatable);
as procedure start-up with intent(out) arguments;
when reaching the end of an executable construct or subprogram, for non-saved local objects;
just before intrinsic assignment to a variable;
after the value of a function's result is finished with.
1If you aren't reading the final form of the document you'll want to pretend paragraphs 5 and 7 don't exist.
I have two different modules each one has the same subroutine. main program will call one of them based on a certain condition. I want to avoid renaming each of these subroutine to a different name.
If you have two modules A and B containing the same method foo() then first you can create a local alias with
program SOModNames
use A, fooA => foo
use B, fooB => foo
implicit none
! Variables
real X(10), Y(10)
call fooA(X,10)
call fooB(Y,10)
end program SOModNames
Unofrtunatelty you cannot scope to a module with call A::foo(X,10) for example.
I am using a parameter to fix the precision of the used types.
This works fine until I try to use the same type within an interface. Consider this small example:
module Hello
implicit none
save
integer, parameter :: K = selected_real_kind(10)
contains
subroutine dosomething(fun)
real(K) :: foo
interface
function fun(bar)
real(K) :: bar
real(K) :: fun
end function fun
end interface
end subroutine
end module
Here, foo would be of the desired type, whereas the compiler (gfortran) complains for 'bar' and 'fun'.
The error is
Error: Parameter 'k' at (1) has not been declared or is a variable, which does
not reduce to a constant expression
Is there a way to get this working?
(For now, I am just writing selected_real_kind(10) everywhere but this is not elegant at all)
Thank you!
The easiest way is to add import inside the interface. It is somewhat of a misdesign that the definitions of the module are outside the scope of the interface. Plain import will import everything.
....
subroutine dosomething(fun)
real(K) :: foo
interface
function fun(bar)
import
real(K) :: bar
real(K) :: fun
end function fun
end interface
end subroutine
....
Also possible: import :: K
When I try to mix both regular procedures and deferred procedures in one abstract type, gfortran balks at any invocation of the regular procedures:
" Error: Base object for type-bound procedure call at (1) is of ABSTRACT type 'tbody' "
type, abstract :: tBody
private
...
contains
procedure :: init => new_Body
...
procedure (contained), deferred :: PointIn
end type tBody
abstract interface
logical(LGT) pure function contained( Body, Point )
import :: tBody, tAffinePoint, LGT
class(tBody), intent(IN) :: Body
type(tAffinePoint), intent(IN) :: Point
end function contained
end interface
subroutine newCuboid( this, ... )
class(tCuboid), intent(OUT) :: this
...
call this%tBody%init( ... )
.... [gfortran halts here]
end subroutine newCuboid
Is there a way to arrange the type tBody so that I can have both abstract, deferred procedures and regular, instantiated procedures?
No.
There's a simple solution - replace call this%tBody%init(...) with call new_Body(...) (you may need to make appropriate accessibility changes).
Possibly feeble rationalisation - you are not resolving the procedure on the basis of the type of the reference (because that's hard coded), so don't use type bound procedure syntax.
Another solution in some cases is to split the type hierarchy further, so that the abstract type tBody has a non-abstract parent that hosts the initial implementation of the "not deferred" procedures.