I am getting confused on the difference between using
Procedure :: momentum => particle_momentum
and using
Procedure :: particle_momentum
generic :: momentum => particle_momentum
Here is a type declaration
type particle
type(vector) :: position, velocity
real :: mass
contains
procedure :: momentum => particle_momentum
procedure :: energy => particle_energy
end type particle
Procedure :: momentum => particle_momentum
defines a type-bound procedure, similar to virtual procedures in other languages. It is a binding of an existing procedure to perform the role of the type-bound procedure.
They use the dynamic dispatch, i.e., when you call
class(particle) :: o
..
call o%momentum
it is possible that if the dynamic type of o is en extended type (child) of particle you actually run a procedure that overrides particle_momentum. You don't know if you actually call the original, or the overriding procedure, until run-time.
Now suppose you have
procedure :: particle_momentum_int
procedure :: particle_momentum_real
generic :: momentum => particle_momentum_int, particle_momentum_real
as
subroutine particle_momentum_real(self, a)
class(particle) :: self
real :: a
subroutine particle_momentum_int(self, a)
class(particle) :: self
integer :: a
Then if you call
class(particle) :: o !or just type(o)
..
call o%momentum(1)
you know that you call the _int variant by the rules of generic disambiguation and you know it at the compile-time. This is the static dispatch.
Simply saying, "generic" is to make life easier, the compiler chooses the suitable form of a procedure among others just by calling a specific command, for example, you want to call the right constructor of an object with "initialize" command. There are some rules should be obeyed the compiler can distinguish them.
On the other hand, "procedure:: x=>y" is employed to override/point one of object procedures (x) to a new function (y).
Related
I'm working on an aerodynamics code (source code here) using good old Fortran. Part of the initialization is reading in a file which contains information on a surface mesh, basically a set of triangular or quadrilateral panels making up the surface. I'd like to describe both quadrilateral and triangular panels using a single type panel. To do that, I've written two initialization functions panel_init_3 and panel_init_4 which will load the data into the type based on how many vertices the panel has. I'd like to bind these to my panel type and overload them based on the number of arguments (i.e. if it gets passed an integer and 3 vertex objects, then panel_init_3 gets called and similarly for 4 vertex objects.
Here is the source code for the type:
module panel_mod
use linked_list_mod
use vertex_mod
implicit none
type panel
! A panel with an arbitrary number of sides
integer :: N ! Number of sides/vertices
type(vertex_pointer),dimension(:),allocatable :: vertices
real,dimension(3) :: n_hat ! Normal vector
real :: A ! Surface area
contains
procedure :: init => panel_init_3, panel_init_4
procedure :: calc_area => panel_calc_area
procedure :: calc_normal => panel_calc_area
end type panel
contains
subroutine panel_init_3(this, v1, v2, v3)
! Initializes a 3-panel
implicit none
class(panel),intent(inout) :: this
type(vertex),intent(in),target :: v1, v2, v3
! Set number of sides
this%N = 3
! Allocate vertex array
allocate(this%vertices(this%N))
! Store info
this%vertices(1)%ptr => v1
this%vertices(2)%ptr => v2
this%vertices(3)%ptr => v3
! Calculate normal vec
! Calculate area
end subroutine panel_init_3
subroutine panel_init_4(this, v1, v2, v3, v4)
! Initializes a panel with 4 sides
implicit none
class(panel),intent(inout) :: this
type(vertex),intent(in),target :: v1, v2, v3, v4
! Set number of sides
this%N = 4
! Allocate vertex array
allocate(this%vertices(this%N))
! Store info
this%vertices(1)%ptr => v1
this%vertices(2)%ptr => v2
this%vertices(3)%ptr => v3
this%vertices(4)%ptr => v4
! Calculate normal vector
! Calculate area
end subroutine panel_init_4
subroutine panel_calc_area(this)
implicit none
class(panel),intent(inout) :: this
end subroutine panel_calc_area
subroutine panel_calc_normal(this)
implicit none
class(panel),intent(inout) :: this
end subroutine panel_calc_normal
end module panel_mod
This module compiles fine. But, when it gets used here
...
! Initialize triangular panel
if (N == 3) then
call panels(i)%init(vertices(i1+1), vertices(i2+1), vertices(i3+1)) ! Need +1 because VTK is 0-indexed
! Initialize quadrilateral panel
else
call panels(i)%init(vertices(i1+1), vertices(i2+1), vertices(i3+1), vertices(i4+1))
end if
...
I get the compiler message
70 | call panels(i)%init(vertices(i1+1), vertices(i2+1), vertices(i3+1), vertices(i4+1))
| 1
Error: More actual than formal arguments in procedure call at (1)
Am I reaching beyond the capabilities of Fortran, or is there a way to do this? I realize I could do this all without binding and overloading, but I like how clean it'd be. I am using gfortran 9.3.0.
In a type-bound procedure declaration statement it's possible to declare more than one binding name in a list, so we can have
type mytype
contains
procedure :: binding1, binding2
end type
giving the two binding names. These are individual bindings. These binding names resolve to procedures with the same name as each. That is, we can write this as
type mytype
contains
procedure :: binding1 => binding1, binding2 => binding2
end type
The list nature of the binding names is such that
type mytype
contains
procedure :: binding => binding1, binding2
end type
has the items in the list binding=>binding1 and binding2. This has effect
like
type mytype
contains
procedure :: binding => binding1, binding2 => binding2
end type
That is, we still have two distinct binding names each binding to a single procedure.
We do not have a generic binding binding name with specific procedures binding1 and binding2. For that, we'd need a generic explicitly created:
type mytype
contains
procedure :: binding1, binding2
generic :: binding => binding1, binding2
end type
In this generic statement, the list has binding1 and binding2 as items as specifics for the generic binding. Precise syntax rules for these lists/statements is given in Fortran 2018 7.5.5.
It is possible, but you need to define init as a generic procedure (binding) with those other two being the specific procedures (bindings)
contains
procedure :: panel_init_3
procedure :: panel_init_4
generic :: init => panel_init_3, panel_init_4
It is quite similar to what is normally done with normal procedures using named interface blocks when you do
interface generic_init
procedure specific_init_3
procedure specific_init_4
end interface
I explain my question in the form of an example.
I have a type (location2d_t) which includes two members x, and y and a type-bound procedure (calcdist2d). The procedure, in addition of (this) with class of (location2d_t), accepts its own type (as second dummy argument) to calculate a distance.
Now, I go further and extend the type to (location3d_t) which has z as well.
To re-define the procedure, I cannot override the previous one so I create a new procedure (calcdist3d) with the second argument of type of (location3d_t) and make a generic procedure (calcdist) for them. In other words, second arguments have different types so generic idea is applicable.
In a more general scope, let's say main program here, for the sake of generality I declare my object as class of parent. When I allocate the object with type of child (location3d_t), a call to (calcdist) whose second dummy argument is (location3d_t) refers to parent generic and says
Error: Found no matching specific binding for the call to the GENERIC 'calcdist'
The code is
module point_mod
implicit none
type location2d_t
integer :: x,y
contains
procedure :: calcdist2d => calcdistance2d
procedure :: here => here_location2d
generic :: calcdist => calcdist2d
end type
type, extends(location2d_t) :: location3d_t
integer :: z
contains
procedure :: calcdist3d => calcdistance3d
procedure, public :: here => here_location3d
generic, public :: calcdist => calcdist3d
end type
contains
function calcdistance2d(this,location) result(output)
class(location2d_t) :: this
type(location2d_t) :: location
integer :: output
output = int(sqrt(real((location%x-this%x)**2+(location%y-this%y)**2)))
end function
function calcdistance3d(this,location) result(output)
class(location3d_t) :: this
type(location3d_t) :: location
integer :: output
output = int(sqrt(real((location%x-this%x)**2+ &
(location%y-this%y)**2+(location%z-this%z)**2)))
end function
subroutine here_location2d(this)
class (location2d_t) :: this
print*, "we are in locationd2d_t"
end subroutine
subroutine here_location3d(this)
class (location3d_t) :: this
print*, "we are in locationd3d_t"
end subroutine
end module
The module is compiled without any error. The below program is implemented to use the module:
program main
use point_mod
implicit none
class (location2d_t), allocatable :: loc
type (location3d_t) :: dum
allocate(location2d_t::loc)
call loc%here() ! calls location2d_t procedure
deallocate(loc)
allocate(location3d_t::loc)
call loc%here() !correctly calls procedure of location3d_t
print*,loc%calcdist(dum) ! gives error
select type (loc)
type is (location3d_t)
print*,loc%calcdist(dum) ! runs well
end select
end program
The procedure "Here" finds its dynamic type correctly. Why isn't generic procedure of child (calcdist) explicitly called ? Do I have to use "select type" block always even in this obvious case?
N.B.: I checked the code with GNU fortran 4.8 and 4.9, and ifort 14.
Yes, you have to use "select type". Outside the "type is" block, loc is polymorphic. Only inside type is (location3d_t), loc has a type and can be passed as dummy argument with defined type.
Generic procedures are always not overridden when the type is extended, so in location3d_t, calcdist is the generic binding for calcdist3d and calcdist2d and loc needs a specific type when calling calcdist to find the appropriate procedure.
When location2d_t is extended, to location3d_t, here binding is overriden and there is only one procedure associated to loc%here() so can be called outside the "type is" block
You can accomplish this behavior without generics with only a slight tweak to your calcdistanceXd functions. The reason you couldn't override the function in your extended type is that the argument type of location was mismatched. If you instead declare location in calcdistance2d to be class(location2d_t) then you can match this in calcdistance3d. You will have to add in a select type construct into calcdistance3d in order to access the members of location3d_t from the polymorphic variable location.
Example:
module point_mod
implicit none
type :: location2d_t
integer :: x, y
contains
procedure, public, pass(this) :: calcdist => calcdistance2d
procedure, public, pass(this) :: here => here_location2d
end type
type, extends(location2d_t) :: location3d_t
integer :: z
contains
procedure, public, pass(this) :: calcdist => calcdistance3d
procedure, public, pass(this) :: here => here_location3d
end type
contains
function calcdistance2d(this, location) result(output)
class(location2d_t) :: this
class(location2d_t) :: location
integer :: output
output = int(sqrt(real((location%x-this%x)**2+(location%y-this%y)**2)))
end function
function calcdistance3d(this,location) result(output)
class(location3d_t) :: this
class(location2d_t) :: location
integer :: output
select type (location)
type is (location3d_t)
output = int(sqrt(real((location%x-this%x)**2+ &
(location%y-this%y)**2+(location%z-this%z)**2)))
class default
output = -1
end select
end function
subroutine here_location2d(this)
class (location2d_t) :: this
print*, "we are in locationd2d_t"
end subroutine
subroutine here_location3d(this)
class (location3d_t) :: this
print*, "we are in locationd3d_t"
end subroutine
end module
With this version of point_mod, your example program works:
program main
use point_mod
implicit none
class (location2d_t), allocatable :: loc
type (location3d_t) :: dum
allocate(location2d_t::loc)
call loc%here() ! calls location2d_t procedure
deallocate(loc)
allocate(location3d_t::loc)
call loc%here() !correctly calls procedure of location3d_t
print*,loc%calcdist(dum)
end program
It is true this approach still requires a select type, but it is hidden in the module implementation rather than being required by users of the module.
Conside the following sample code:
module mod
implicit none
type :: typeBase1
integer :: A1
end type
type :: typeBase2
integer :: A3
end type
type :: typeBase3
integer :: A3
end type
type, extends(typeBase1) :: typeDerived1
! Void
end type
type, extends(typeBase2) :: typeDerived2
! Void
end type
type, extends(typeBase3) :: typeDerived3
! Void
end type
type, extends(typeBase1) :: typeDerived11
! Void
end type
type, extends(typeBase2) :: typeDerived21
! Void
end type
type, extends(typeBase3) :: typeDerived31
! Void
end type
type :: complexType
class(typeBase1), pointer :: ptrBase1 ! typeBase1, 2 and 3 are extensible
class(typeBase2), pointer :: ptrBase2
class(typeBase3), pointer :: ptrBase3
end type
interface calcul
subroutine calculA(obj1, obj2, obj3)
import
type(typeDerived1) :: obj1 ! typeDerived 1, 2 et 3 are derived type of typeBase1, 2 and 3
type(typeDerived2) :: obj2
type(typeDerived3) :: obj3
end subroutine
subroutine calculB(obj1, obj2, obj3)
import
type(typeDerived11) :: obj1 ! typeDerived 11, 21 et 31 are derived type of typeBase1, 2 and 3
type(typeDerived21) :: obj2
type(typeDerived31) :: obj3
end subroutine
end interface calcul
contains
subroutine calculComplexType(complex)
type(ComplexType), intent(inout) :: complex
call calcul(complex % ptrBase1, complex % ptrBase2, complex % ptrBase3)
end subroutine
end module mod
What I am trying to do is that the subroutine calculComplexType calls a different version of the subroutine calcul, basing on the dynamic type of ptrBase1, ptrBase2 and ptrBase3.
The code does not work, because the compiler looks for a subroutine with the following interface:
subroutine calcul(obj1, obj2, obj3)
class(typeBase1) :: obj1
class(typeBase1) :: obj2
class(typeBase1) :: obj3
end subroutine
whatever the dynamic type of ptrBase1, ptrBase2 and ptrBase3 is.
My question is: is there a way in Fortran to write the interface calcul in order to automatically select a procedure basing on the dynamic type of the arguments?
I would like to avoid to use a long sequence of "select class".
Any suggestion to rewrite the code is welcome!
If you request dispatch based on all three arguments, it cannot be done. Some languages offer so called multimethods for this.
In Fortran you can use normal single dispatch methods (type-bound procedures), but in that case it can choose the subroutine only according to one argument.
Otherwise you have to use select the select type construct and make a case for every possible combination, be it inside one single procedure, or to select between more versions of it.
For two arguments, you can also consider the double dispatch pattern.
This is simply not possible in Fortran; the best you can do with polymorphism is to use an overridden type-bound procedure, selecting a function based on the dynamic type of one particular entity.
However, depending on the nature of what calcul does, it may make more sense to define just one version of calcul that takes polymorphic arguments (i.e. class(typeBase1), class(typeBase2), class(typeBase3)), and deal with the dynamic type inside calcul itself. The benefits are twofold:
calcul may be able to test the type of each argument independently from the others. If that is the case, you will still have to write three select type constructs, but they won't be nested or duplicated.
It's likely that you can use single dispatch (with type-bound procedures) to remove the need for a select type construct completely.
It's difficult for me to think of a situation where the code in this question is really the best design you could use.
If calcul is really doing something completely "different" for each dynamic type, in a way that's relevant to the code that calls it, then the calling code should not be using polymorphic pointers (e.g. perhaps there should be a different complexType for each different calcul).
But if every version of calcul is doing essentially "the same" operation (as far as higher-level code knows/cares about), regardless of dynamic type, then there should only be one version and it should accept arguments that are of the base class.
I am writing a library for importing geometries of many types (spheres,planes,NURBS surfaces, stl files...) into a scientific Fortran code. This kind of problem seems taylor-made for OOP because it is simple to define a type :: geom and then type,extends(geom) :: analytic and so on. The part I am having trouble with is the file IO.
My solution at this point is to write the parameters defining the shapes, including some flags which tell me which shape it is. When reading, I instantiate a class(geom) :: object, (since I don't know ahead of time which subtype it will be) but how can I read it?
I can't access any of the specific components of the subtype. I read that downcasting is verboten, and besides, the new allocate(subtype :: class) doesn't seem to work. The new READ(FORMATTED) doesn't seem to be implemented by ifort or gfortran. i.e.
module geom_mod
type :: geom
end type
type,extends(geom) :: sphere
integer :: type
real(8) :: center(3),radius
contains
generic :: READ(FORMATTED)=> read_sphere ! not implemented anywhere
end type
contains
subroutine read_geom(object)
class(geom),intent(out),pointer :: object
integer :: type
read(10,*) object%type ! can't access the subtype data yet
read(10,*) type
backspace(10)
if(type==1) then
allocate(sphere :: object)! downcast?
read(10,*) object ! doesn't work
end if
end read_geom
end module
Am I going about this all wrong? I could hack this using something other than polymorphism, but this seems cleaner everywhere else. Assistance would be greatly appreciated.
EDIT: sample program using IanH's module
program test
use geom_mod
implicit none
class(geom),allocatable :: object
open(10)
write(10,*) '1'
write(10,*) sphere(center=0,radius=1)
rewind(10)
call read(object) ! works !
end program test
Current gfortran and ifort do not implement defined input/output. I have not seen any evidence that this situation will change in the near future. However, apart from allowing some syntactic shortcuts that feature does not actually save you much work here.
One approach for this situation is to call a "factory" for extensions of geom that uses the data in the file to allocate the argument to the correct type, then hand off to a type bound procedure that reads in the type specific data. For example:
module geom_mod
implicit none
integer, parameter :: dp = kind(1.0d0)
type, abstract :: geom
contains
procedure(read_geom), deferred :: read
end type geom
abstract interface
subroutine read_geom(object)
import :: geom
implicit none
class(geom), intent(out) :: object
end subroutine read_geom
end interface
type, extends(geom) :: sphere
real(dp) :: center(3), radius
contains
procedure :: read => read_sphere
end type sphere
contains
subroutine read(object)
class(geom), intent(out), allocatable :: object
integer :: type
read (10, *) type
! Create (and set the dynamic type of object) based on type.
select case (type)
case (1) ; allocate(sphere :: object)
case default ; stop 'Unsupported type index'
end select
call object%read
end subroutine read
subroutine read_sphere(object)
class(sphere), intent(out) :: object
read (10, *) object%center, object%radius
end subroutine read_sphere
end module geom_mod
Current ifort (12.1.5) has issues with intent(out) polymorphic arguments that may require workarounds, but the general approach remains the same.
(Note that the subroutine read is not a type bound subroutine - to read a generic geom object use ''call read(object)'' in the conventional subroutine reference style.)
I'm writing a linked list structure in Fortran2003. The nodes in this linked list come in two varieties that alternate. The list represents a topological ring of edges, each edge is bounded by two vertices, and each vertex connects to two edges.
These structures are declared as an abstract NODE_T type, and implemented by two subclasses, VN_T and EN_T. A VN_T points to two EN_Ts, and vice versa.
Since the list alternates between types, the pointers are stored in the subclasses.
My problem is with adding type bound functions (methods?) to VN_T and EN_T that are called NEXT() and PREV(), and that do the right thing via polymorphism. VN_T%NEXT() should skip on two steps, and get the next VN_T (that is separated from the starting one by an EN_T).
My type/class definitions are as follows:
TYPE, ABSTRACT :: NODE_T
INTEGER :: IENT
INTEGER :: ISIDE
INTEGER :: ISUBTYPE
INTEGER :: IPAD
CONTAINS
PROCEDURE(NEXTA), DEFERRED :: NEXT
PROCEDURE(PREVA), DEFERRED :: PREV
END TYPE NODE_T
ABSTRACT INTERFACE
FUNCTION NEXTA(PENT)
IMPORT NODE_T
CLASS(NODE_T), POINTER :: NEXTA
CLASS(NODE_T) :: PENT
END FUNCTION
FUNCTION PREVA(PENT)
IMPORT NODE_T
CLASS(NODE_T), POINTER :: PREVA
CLASS(NODE_T) :: PENT
END FUNCTION
END INTERFACE
TYPE, EXTENDS(NODE_T) :: VN_T
DOUBLE PRECISION DT
CLASS(EN_T), POINTER :: N
CLASS(EN_T), POINTER :: P
CONTAINS
PROCEDURE :: NEXT => NEXTV
PROCEDURE :: PREV => PREVV
END TYPE
TYPE, EXTENDS(NODE_T) :: EN_T
CLASS(VN_T), POINTER :: N
CLASS(VN_T), POINTER :: P
CONTAINS
PROCEDURE :: NEXT => NEXTE
PROCEDURE :: PREV => PREVE
END TYPE
The implementations of the next/prev routines are all much the same, the four combinations of next/prev and EN/VN:
FUNCTION NEXTE(PENT)
CLASS(NODE_T), POINTER :: NEXTE
CLASS(EN_T) PENT
NEXTE => PENT%N%N
END FUNCTION
When I call these functions:
CLASS(NODE_T), POINTER :: NODE1, NODE2
NODE2 => NODE1%NEXT()
Then my compiler (Intel FORTRAN XE Composer 2011, i.e. v12.0) complains with the message
error #8314: If the rightmost part-name is of abstract type, data-ref shall be polymorphic [NEXT]
NODE2 => NODE1%NEXT()
---------------------------^
Which based on this this documentation seems to indicate that it is trying to call the procdure NEXT on the base class rather than selecting one of the subclass implementations (which it should be able to do based on the concrete type of NODE1 which is on the right hand side, right?).
I'm new at the OOP features of F2003, so I made a mockup of this pattern in JAVA which I got working to my satisfaction. Can anyone shed light on whether this is either a) a difference in the OOP behaviour of F2003, 2) a compiler bug or 3) just me being braindead...
You may need to update your compiler. As discussed in this thread
http://software.intel.com/en-us/forums/showthread.php?t=78855
the Fortran standard originally disallowed calling type-bound procedures of abstract types directly, which you are trying to do. However, the standard was changed and it should have made it into Intel Fortran by now.
An alternative is to modify the base class as:
TYPE :: NODE_T
INTEGER :: IENT
INTEGER :: ISIDE
INTEGER :: ISUBTYPE
INTEGER :: IPAD
CONTAINS
PROCEDURE :: NEXT
PROCEDURE :: PREV
END TYPE NODE_T