polymorphic pointer assignment

[Li_Dong]

Hi all,

I am trying to use polymorphic pointer, that can be pointed to different types of variables. For example:

[fortran]program test_poly_pointer

    implicit none

    type base_type
        character(10) name
    end type base_type

    type, extends(base_type) :: type1
        integer value
    end type type1

    type, extends(base_type) :: type2
        real value
    end type type2

    class(base_type), pointer :: ptr
    type(type1), target :: a
    type(type2), target :: b

    ptr => a
    ptr%value = 1
    write(*, *) a%value

    ptr => b
    ptr%value = 1.0
    write(*, *) b%value

    stop

end program test_poly_pointer[/fortran]

The Intel Fortran compiler 11.0 084 on Mac OS X gives the following error output:

test_poly_pointer.f90(22): error #6460: This is not a field name that is defined in the encompassing structure. [VALUE]

p%value = 1

------^

compilation aborted for test_poly_pointer.f90 (code 1)

test_poly_pointer.f90(22): error #6460: This is not a field name that is defined in the encompassing structure. [VALUE] p%value = 1------^compilation aborted for test_poly_pointer.f90 (code 1)

Any idea?

Cheers,

DONG Li

[david_car]

You need to use a select type construct to cast your pointer to the correct type as follows:

[bash]program test_poly_pointer

    implicit none

    type base_type
        character(10) name
    end type base_type

    type, extends(base_type) :: type1
        integer value
    end type type1

    type, extends(base_type) :: type2
        real value
    end type type2

    class(base_type), pointer :: ptr
    type(type1), target :: a
    type(type2), target :: b

    select type( ptr => a )
    type is ( type1 )
        ptr%value = 1
        write(*, *) a%value
    end select

    select type( ptr => b )
    type is ( type2 )
        ptr%value = 1.0
        write(*, *) b%value
    end select

    stop

end program test_poly_pointer[/bash]

[Li_Dong]

Hi David,

Thanks for replying. I am not familiar with "select type" syntax, and what does "ptr =gt; a" mean?

I have searched in Google about "polymorphic pointer assignment", and I have found "unlimited polymorphic entities" in book "Fortran 95/2003 explained" on page 274:

[fortran]class(*), pointer :: up
...
real, target :: x
...
up => x[/fortran]

As you can see, it just points "up" to "x" directly. Does this programming pattern work in any way?

Cheers,

DONG Li

[msbriggs]

There is an html rendering problem with David's code example. & gt ; should be the greater than symbol, to indicate pointer assignment between ptr and a. But when I made that change, ifort 11.1-84 gave an error message. I made the some minor changes to David's example, following an example in The Fortran 2003 Handbook by Adams, et al. and reached a code example that compiled. I'm also learning these new features....

[fortran]program test_poly_pointer  
  
    implicit none  
  
    type base_type  
        character(10) :: name  
    end type base_type  
  
    type, extends(base_type) :: type1  
        integer :: value  
    end type type1  
  
    type, extends(base_type) :: type2  
        real :: value  
    end type type2  
  
    class(base_type), pointer :: ptr  
    type(type1), target :: a  
    type(type2), target :: b  
  
    write (*, *) 'Test ONE'
    ptr => a
    select type ( ptr )  
       type is ( type1 )  
           ptr%value = 1  
           write(*, *) a%value  
       type is ( type2 )  
           ptr%value = 1.0  
           write(*, *) b%value  
    end select
    
    write (*, *) 'Test TWO'
    ptr => b
    select type ( ptr )  
       type is ( type1 )  
           ptr%value = 1  
           write(*, *) a%value  
       type is ( type2 )  
           ptr%value = 1.0  
           write(*, *) b%value  
    end select  

  
    stop  
  
end program test_poly_pointer  [/fortran]

[Izaak_Beekman]

My experience so far is that Intel compiler support for these OOP features is limited. Either the features you need have not been introduced yet, or there is a compiler bug for some of the newer features which have been introduced. For example, I had a code with some fancy 2003 OOP features which would run fine until I passed the compiler (11.1 046) certain debug flags (-O0 or -g) at which point the code would execute a an incorrect branch, completely unrelated to the new F2003 features I was using. (I have a command line option parsing routine, and when compiled with the debug flags it parses the optionsincorrectly, but it works fine without the debug flags. Note to Intel: I will try to find a simple test case sometime soon, but as I do not have access to my organizations premier.intel account, and the code base exercising the bug is rather large and non-trivial I don't know how soon I'll be able to create reproducer code.)

For your reference here is the brief list of 2003 supported features for the latest intel compiler:

http://software.intel.com/en-us/articles/intel-fortran-compiler-support-for-fortran-language-standards/

(Note I think someone should make this sticky and put it in the useful links section at the top of the forum, I always have trouble finding it when I want it.)

Also here is the April ACM SIGPLAN Fortran Forum 2003 compiler compatibility matrix:

http://portal.acm.org/citation.cfm?id=1753169&dl=ACM&coll=portal&CFID=83684400&CFTOKEN=70135260

[Steven_L_Intel1]

The list of supported standard features can be found in the compiler release notes. Yes, we have had bugs in the OO support, as have all compiler vendors, and we fix them as soon as we can.

[Izaak_Beekman]

Sorry, I didn't mean to be too cantankerous, I do like the Intel compilers over all, I just meant to say that for the time being it is probably safer to stick to the 95 standard, except for simpler, and well supported f2003 features, such as the PROTECTED attribute. As far as I can tell, from experience and the compiler support matrix on the ACM SIGPLAN Fortran Forum Intel has everyone, except perhaps Cray, beat in terms of f2003 compatibility. Ipersonallyhave never used the Cray compiler, so I cannot directly compare it, except through personally unverified hearsay.

[Steven_L_Intel1]

IBM xlf has pretty much all of F2003. We're probably third overall.

I agree that the OO features have some rough edges, but by the current update 5 we've managed to smooth off most of those. Lots of work remains.

[Li_Dong]

Hi,

It is great to see the progress of OO support of Fortran. As the development of technology, traditional Fortran shows its shortage on modern programming pattern for developing more flexible code, but it is fast and adopted by all most all of researchers in my domain. So I hope Fortran and Intel Fortran compiler can have good future!

Cheers,

DONG Li