class (base_type), pointer :: btp
...
select type (base_type)
type is (extended_type)
if (a .lt. b) then
...
end if
end select
everything works out fine. But if I try and use these operators with
the extended type directly a compiler error returns. An example code
that does this with gfortran 4.7.0 20110430 is:
module foo_module
implicit none
type, abstract :: foo
contains
procedure (assign_interface), deferred :: assign
generic :: assignment(=) => assign
end type
abstract interface
subroutine assign_interface(lhs,rhs)
import :: foo
class(foo), intent(inout) :: lhs
class(foo), intent(in) :: rhs
end subroutine
end interface
end module
module bar_module
use foo_module
implicit none
type, extends(foo) :: bar
real :: x
contains
procedure :: assign => assign_bar
end type
contains
subroutine assign_bar(lhs,rhs)
class(bar), intent(inout) :: lhs
class(foo), intent(in) :: rhs
select type(rhs)
type is (bar)
lhs%x = rhs%x
end select
end subroutine
end module
program main
use foo_module
use bar_module
implicit none
type(bar) :: one, two
one%x = 1
two%x = 2
one = two
end program
which produces the error:
undefined reference to `assign_interface_'
Is that code standard conforming? If not, why can't overloaded
operators be used this way? It seems very much like assign_interface is
defined, which makes this all the more confusing.
I suggest you report the bug to gfortran.
Cheers,
Jim
Works with nagfor 5.2. Note that the error message is issued by the
linker. This suggests that gfortran is generating wrong code since
assign_interface should not appear anywhere in the object code.
-- Wolfgang
--
E-mail: firstnameini...@domain.de
Domain: yahoo
This is more of a question than an answer, but there is a difference
between the abstract interface and the interface of subroutine
assign_bar. The dummy argument lhs is declared as class(foo) in one, and
as class(bar) in the other. Is that allowed?
I'll have a look at the standard and see if I can find an answer myself.
Erik.
The difference is actually mandated IUIC. The passed dummy argument
must
have the class/type of the type in which the type-bound procedure
occurs.
All other arguments should have the same type, as should the return
value.
Regards,
Arjen
Ok, so it's not just allowed, it's the way it should be done. When I
think about it, it makes sense of course; you can't define a subroutine
with a dummy argument of abstract type.
Erik.
I read your reply just after posting the reply to myself.
I guess the abstract type was distracting me. Even if the parent type is
not abstract, the interfaces should differ in the passed dummy argument,
right?
Erik.