Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
1 View

unlimited polymorphic parameter and transfer intrinsic

Trying to use polymorphism with the transfer intrinsic, I ran into a behaviour that I don't understand.

With the following test program, i get the following output :

storage req. size =           16

text = h!O�p!O��

If I replace "class default" with "class is (str)", I get the expected :

storage req. size =           16

text = hello !

Am I doing something wrong ?

Thanks !

Franck

module polymorphic

   character(len=1), private, dimension(:), allocatable :: storage

   type  str
       character(len=16) :: text
   end type str

contains
   subroutine store(arg)
      implicit none

      class(*), intent(in)      :: arg

      integer   :: i_size
      type(str) :: probe

      select type (arg)
!         class is (str)
         class default
            i_size = size(transfer(arg,storage))
            write (*,*) ' storage req. size = ',i_size
            allocate(storage(i_size))
            storage = transfer(arg,storage)

            probe = transfer(storage, probe)
            write (*,*) 'text = ', probe%text
     end select
   end subroutine store

end module polymorphic


program test_polymorphic
  use polymorphic

  type(str) :: input
  input%text = 'hello !'
  
  call store(input)
  
end program test_polymorphic

 

0 Kudos
7 Replies
Highlighted
1 View

With "class default" and a

With "class default" and a class(*) selector, arg is polymorphic and has no declared type. I'm unsure if it's really legal to reference arg in that context. The definition of TRANSFER says that the source can be "any type" but it in fact has NO type. The compiler really ought to give you an error here, but I want to research this some more before I file a bug report.

Nevertheless, I don't think you can get away with what you're doing here.

Retired 12/31/2016
0 Kudos
Highlighted
1 View

Ok, did some more research

Ok, did some more research and I concluded that this ought to work. It seems we're not handling polymorphic arguments to TRANSFER correctly. (Interpretation F03/0047 confirmed that either SOURCE or MOLD may be polymorphic.)  I filed issue DPD200408903 about this and will let you know of any progress.

Retired 12/31/2016
0 Kudos
Highlighted
1 View

Steve,

Steve,

What happens with transfer in the above when inside type str, text is declared as allocatable?
Wouldn't then the (image of the) array descriptor be treated as the character(1) array?

Jim Dempsey

0 Kudos
Highlighted
1 View

Yes, I think that's what

Yes, I think that's what would happen.

Retired 12/31/2016
0 Kudos
Highlighted
Beginner
1 View

Quote:Steve Lionel (Intel)

Steve Lionel (Intel) wrote:

Ok, did some more research and I concluded that this ought to work. It seems we're not handling polymorphic arguments to TRANSFER correctly. (Interpretation F03/0047 confirmed that either SOURCE or MOLD may be polymorphic.)  I filed issue DPD200408903 about this and will let you know of any progress.

Thanks a lot Steve. Quick and accurate answer.

Do you ever stop monitoring the forum ? (first part of your answer was on Sunday night, right ?)

Franck

0 Kudos
Highlighted
1 View

Yes, that was Sunday night.

Yes, that was Sunday night. Bugs never sleep.

Retired 12/31/2016
0 Kudos
Highlighted
1 View

I expect this bug to be fixed

I expect this bug to be fixed in Update 2 to Parallel Studio XE 2017.

Retired 12/31/2016
0 Kudos