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

Intrinsic assignment with defined assignment(=) in for components

17 views
Skip to first unread message

Tobias Burnus

unread,
Dec 13, 2010, 11:05:23 AM12/13/10
to
Hello,

[Longer example below.] Assuming a type

type t
type(component) :: foo
end type

where a defined assignment has been defined for the type "component" but
not for "t". If one now does

type(t) :: a, b
! ...
a = b

Will be the defined or the intrinsic assignment used for the "foo"
component? My understanding is that it depends one the way one has
created the defined assignment: If one uses "INTERFACE ASSIGNMENT(=)",
it is not invoked; however, if it is defined as type-bound assignment,
it is used.

(The compilers seem to be consistent in not invoking it for the
"interface assignment(=)", but for the version with type-bound
assignment, different compilers produce different results [invoking it,
not invoking it, internal compiler error].)

Do you read the standard the same way?

From F2008, Chapter 7.2.1.3:

"An intrinsic assignment where the variable is of derived type is
performed as if each component of the variable were assigned from the
corresponding component of expr using pointer assignment (7.2.2) for
each pointer component, defined assignment for each nonpointer
nonallocatable component of a type that has a type-bound defined
assignment consistent with the component, intrinsic assignment for each
other nonpointer nonallocatable component, [...]"


Example:


module m
implicit none

! Variant (A)
type component
contains
procedure :: assign
generic :: assignment(=)=>assign
end type

! Variant (B)
!
! type component
! end type
! interface assignment(=)
! module procedure assign
! end interface

type t
type(component) :: foo
end type

contains

subroutine assign(lhs,rhs)
class(component), intent(out) :: lhs
class(component), intent(in) :: rhs
print *,'defined assignment called'
end subroutine

end module

program main
use m
implicit none
type(t) :: infant, newchild
infant = newchild
end


Tobias

PS: Based on GCC bugreport PR 46897

Richard Maine

unread,
Dec 13, 2010, 11:25:35 AM12/13/10
to
Tobias Burnus <bur...@net-b.de> wrote:

> [Longer example below.] Assuming a type
>
> type t
> type(component) :: foo
> end type
>
> where a defined assignment has been defined for the type "component" but
> not for "t". If one now does
>
> type(t) :: a, b
> ! ...
> a = b
>
> Will be the defined or the intrinsic assignment used for the "foo"
> component? My understanding is that it depends one the way one has
> created the defined assignment: If one uses "INTERFACE ASSIGNMENT(=)",
> it is not invoked; however, if it is defined as type-bound assignment,
> it is used.

I agree with your assessment. Defined assignment in f90/f95 had gaping
loopholes. It got "dropped" in all kinds of contexts and you ended up
using the intrinsic assignment instead. It was darned difficult to make
sure that you actually always used the defined assignment. Those
problems couldn't be remedied without breaking codes that used the
feature as specified in f90/f95. Type-bound assignment is much more
consistent and doesn't get "dropped". If you define a type-bound
assignment, it is going to get used darn near everywhere. I might even
say that the non-type-bound version might be destined for obsolescnence
someday, though obviously the day won;t be soon, as the type-bound
replacement isn't til f2003, which doesn't even have full compilers yet
(on any machines I can get at).


> (The compilers seem to be consistent in not invoking it for the
> "interface assignment(=)", but for the version with type-bound
> assignment, different compilers produce different results [invoking it,
> not invoking it, internal compiler error].)

Well, internal compiler error is... you know that drill. And type-bound
assignment is an f2003 feature, so compilers probably can claim they
haven't yet completed f2003.



> Do you read the standard the same way?

Yep.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

0 new messages