Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Deferred Overloaded Assignment

17 views
Skip to first unread message

Andrew Baldwin

unread,
May 9, 2011, 8:05:48 PM5/9/11
to
I'm trying to create an abstract type that will act as a prototype for
all data components of our binary search tree data structure.
Accordingly, I have deferred overloaded operators defined for the
abstract type that are later implemented by the extending types. When I
access these operators through something like

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.

Jim Xia

unread,
May 9, 2011, 9:56:36 PM5/9/11
to
Your code looks standard conforming to me. XLF compiles it without
any errors.

I suggest you report the bug to gfortran.

Cheers,

Jim

Wolfgang Kilian

unread,
May 10, 2011, 3:04:23 AM5/10/11
to

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

Erik Toussaint

unread,
May 10, 2011, 6:29:20 AM5/10/11
to

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.

Arjen Markus

unread,
May 10, 2011, 6:51:35 AM5/10/11
to

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

Erik Toussaint

unread,
May 10, 2011, 6:54:38 AM5/10/11
to
On 10-5-2011 12:29, Erik Toussaint wrote:
> 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.

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.

Erik Toussaint

unread,
May 10, 2011, 7:00:39 AM5/10/11
to

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.

0 new messages