I read this link, it talks about Self-defining INTERFACE.
But I got confused about the saying
A Procedure should be able to read it’s own interface specification in
and INTERFACE block.
What is own interface specification? What does this link mean?
Before I start: This is about explicit interfaces. If in doubt, you should use MODULES so you don't have to worry about this.
Now to the question.
If you have a function, say this:
function square(a)
implicit none
real, intent(in) :: a
real :: square
square = a * a
end function square
And this function is in a separate file, to be compiled separately from the calling routine, then it would be advisable that the calling routine is told of the interface of this function. Something like this:
interface
function square(a)
implicit none
real, intent(in) :: a
real :: square
end function square
end interface
should be in the calling routine's declaration block. This way, the calling routine, while not knowing how the square function works, knows what types of parameters to pass to it, and what to expect back.
It is quite common to put this into a separate file, and include this file everywhere this function might be called.
Here's the issue: There are no checks that the interface block actually matches the real thing. So the idea of this proposal seems to be that in the code implementing the square function, you should be able to also include this separate file and then the compiler could check whether the interface block matches the declaration, and throw an error if wrong.
At the moment, though, including this interface block is explicitly forbidden by the standard.
Related
Use case: A particular type of subroutine can be used as an argument to another one. What is the best way to avoid code duplication and ensure that all the subroutines intended for use in this argument are defined in the same consistent way?
Something similar is addressed in https://stackoverflow.com/a/34936204 (i.e., use abstract interface foo to declare the common interface and procedure(foo) to declare the dummy argument). But this is for reusing the same interface block in different subroutines. My main problem is how to ensure that the actual implementation of all the "target" procedures conforms to that interface.
A promising feature was that of module procedure in submodules, where the interface declaration is in the parent module, and the actual implementation does not need re-declare all the dummy arguments and types. But this does does not allow having different implementations for the same interface (or maybe it does using some combination with the above, but they'd still have to be included in the same module, which is something I'd like to avoid).
dummy example:
program main
...
call foo(sub1,x,y)
call foo(sub2,x,y)
call foo(sub3,x,y)
call foo(sub4,x,y)
call foo(sub5,x,y)
...
end program main
subroutine foo(f,a,b)
...
call f(a,b,c,d,e,g,h,i...)
...
end subroutine foo
All sub1...sub5 subroutines have a common interface, and I'd like to define the long list of dummy arguments only once.
I have intention to point with the same procedure to two different procedures but I have not experienced programmer in Fortran so I need help.
This is my simple code:
module types
type :: type_one
integer, private :: a1,a2
contains
procedure, public :: f_data => set_data_a1
procedure, public :: f_data => cal_data_a2
end type type_one
private :: set_data_a1,cal_data_a2
contains
integer function set_data_a1(this)
class(type_one) :: this
this%a1 = 2
end function set_data_a1
integer function calc_data_a2(this)
class(type_one) :: this
this%a2 = this%a1 + 3
end function calc_data_a2
end module types
program types_pro
implicit none
type(type_one) :: type_obj
type_obj%f_data()
end program types_pro
I got this error:
`There is already a procedure with binding name 'f_data' for the derived type 'type_one' |
Is it possible to call both procedures at the same time with type_obj%f_data()?
A generic name, such as your f_data, allows calling procedures with different input signatures (rank, type, kind, and number of arguments) by the same name. But, because they have the same argument signatures the compiler can't determine which of calc_data_a1 and calc_data_a2 to execute when your code makes a call to f_data.
Which leads me to a question for you: How do you expect the compiler or code to behave ? What do you want the compiler to do ? (OK that was two questions.)
As a general rule, if you want the compiler to execute two procedures you have to make two calls. You could, I suppose, have one procedure call the other if you want both to run when one is called.
If you want to wrap multiple functions behind the same name they have to have different input signatures so that the compiler can work out which one to call.
Obviously my earlier version of this answer wasn't explicit enough:
No, there is no way to write your code to execute two different procedures in response to a single call to one of them. (Unless, that is, the one calls the other.) Furthermore, it is unreasonable to expect a single (procedure) pointer to point, at any one time, at more than one target.
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.
For instance, I have a definition of type A in moduleA:
Module moduleA
implicit none
type A
private
integer::N
contains
...
procedure,pass::f=>f1
endtype
private::f1
contains
real function f1(self,x)
real::x(self%n)
end function
...
end Module
Then I found I meet a trouble when I override function f in other modules since I can not get the value of N. Even though I can have a method to get that, it seems that something like real :: x(self%get()) is impossible in the declaration. I want to keep the rule of "private" in OPP. So what choices can I have?
You cannot do that. At least in the way you describe. It would be better to see an example of the overriding to suggest other options.
The private attribute works differently in Fortran and therefore you should not directly use rules from other languages that use OOP where private means something different.
In Fortran private is about the local module, in C++ it is about the derived classes. This is very different and you cannot use the C++ (or Java, etc.) rules for private in Fortran when private in fact means something else.
To be clear, I assume you wanted this kind of overriding:
real function f2(self,x)
class(B) :: self
real::x(self%get())
end function
You than get these messages:
private.f90(15): error #8497: Illegal use of a procedure name in an expression, possibly a function call missing parenthesis. [GET]
real::x(self%get())
---------------------^
or
real::x(self%get())
1
Error: 'get' at (1) should be a FUNCTION
So the compilers will not accept a type-bound procedure in the declaration. They would accept an ordinary procedure.
This compiles in gfortran, but not in Intel Fortran. But get() must be public, which you might not want:
real function f1(self,x)
class(A) :: self
real::x(get(self))
end function
real function f2(self,x)
class(B) :: self
real::x(get(self))
end function
In ifort I get
error #8383: The dummy arguments of an overriding and overridden binding that correspond by position must have the same characteristics, except for the type of the passed object dummy arguments.
which is weird.
I am writing some simulation code (almost) from scratch and want to use OOP features from fortran to keep it easier to maintain. I've learned in a fortran workshop, that one should be carefull when using OOP features within performance critical parts of the code.
My naive first approach (ignoring the warning) would be the following snippet. The background is the calculation of a system energy which needs an interaction potential. For this potential, I use an abstract type (potential). All users can then add their own potentials as extensions and define a keyword that is used to allocate their potential. The energy calculation in the main program does not change.
module system_mod
implicit none
type, abstract :: potential
contains
procedure(init), deferred :: init
procedure(eval), deferred :: eval
end type
type, extends(potential) :: my_potential
! some parameters
contains
procedure :: init => init_my_potential
procedure :: eval => eval_my_potential
end type
! omitted: other extensions of 'potential'
! and abstract interface of potential
type :: system
! some components
class(potential), allocatable :: pair_potential
contains
procedure :: init ! subroutine, which is used to allocate pair_potential depending on a passed keyword
end type
contains
! implementation of all routines
end module system_mod
program main
use system_mod, only: potential, my_potential, system
implicit none
character(len=3) :: keyword !
integer :: i
real :: coordinates(n,3) ! n is a huge number
real :: energy, system_energy
type(system) :: test_system
call test_system%init ( keyword )
! keyword tells which of the extensions of 'potential' is allocated
do i = 1, n
energy = test_system%pair_potential%eval ( ... )
system_energy = system_energy + energy
end do
end program
I think my main problem concerning the performance is that I don't get what the compiler actually does at compile time and which things are done at run time.
So my questions are:
How or when does the compiler check, which instance of 'eval' to use?
When the keyword is known at compile time, is there a type check in every iteration of the loop?
Would it be better to, for example, use a procedure pointer in the main program, and associate it at the beginning to the according 'eval' procedure?
Thank you very much in advance!
It has a virtual table of procedures that are possible to be called for the binding for all extended types and decides in run-time from this table.
Setting keyword may not help, it depends on how much the compiler is clever. I would use type instead of class if the type is known at the compile time. This is very likely to skip the vtable look-up.
The procedure pointer will affect the flow of the instructions too, although you may save some part of the vtable look-up. This really depends on the internals and is worth a try and some performance measurement.