Circular class reference allowed?

[dwwade]

I think I have got myself into trouble and I would like someone to verify for me that I am in fact doing something that is illegal.

I have a type that has multiple derived type that has a pointer to another type that has multiple derived types, thus I use the

type :: child_type

class(parent_type), pointer :: cb

! other stuff including a contains and procedures

end type child_type

! several more child types derived from original child_type

type :: parent_type

class(child_type), pointer :: orb

end type parent_type

! a couple of more parent types

When I do this, it gives me an error saying that the name must have an explicit type for the "class(parent_type), pointer :: cb" line.

Is there a trick to make it work?

Darren

[Steven_L_Intel1]

Please post the actual code that gives you the error. The paraphrase you posted does not - at least not in 12.1.5 or 13.0.1. Which specific compiler version are you using?

[dwwade]

Version I'm using: Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 12.0.2.154 Build 20110112. I've been commenting out and removing stuff from a version of the file to see if it something else causing it. [fortran] module Orbit implicit none type :: cbody_type integer :: plid = -1 logical :: spkdata = .false. real*8 :: mu = 0 real*8 :: radii(3) = 0 real(8) :: vol_radius = 0 real*8 :: flattening = 0 character*(20) :: cbname = "" class(orbit_type), pointer :: ephem => null() ! contains end type cbody_type type, extends(cbody_type):: custom_cbody_type integer :: astid end type custom_cbody_type type :: orbit_type ! top level class integer :: etype = 0 class(cbody_type), pointer :: cbody => null() ! contains ! procedure :: posvel => orbit_rv ! dummy procedure which can pass to lower procedure ! procedure :: setorb => orbit_set ! dummy procedure which can pass to lower procedure end type orbit_type type, extends(orbit_type) :: rvorbit_type ! base coordinate system is EMO 2000 which is in spice called EclipJ2000 integer :: conic = 0 ! -1: rectilinear, 0: undefined, 1: circle, 2: ellipse, 3: parabola, 4: hyperbola real*8 :: elements(6) = 0 ! position and velocity at epoch real*8 :: epoch = 0 ! epoch of elements real*8 :: input(6) ! real*8 :: itype ! input type variable described by orbin contains procedure :: posvel => rvorbit_rv ! dummy procedure which can pass to lower procedure procedure :: setorb => rvorbit_set ! dummy procedure which can pass to lower procedure end type rvorbit_type type, extends(orbit_type) :: spkorbit_type integer :: spiceid contains procedure :: posvel => spkorbit_rv ! dummy procedure which can pass to lower procedure procedure :: setorb => spkorbit_set ! dummy procedure which can pass to lower procedure end type spkorbit_type type :: orblist_type class(orbit_type), pointer :: orbit => null () end type orblist_type type :: cblist_type class(cbody_type), pointer :: cb => null () end type cblist_type character(30) :: spicekernel = 'spice.ker' integer :: frame = 0 ! 0 is default EMO2000 character(30) :: framename = 'ECLIPJ2000' type (cblist_type) :: cblist(0:12) class(orbit_type),pointer :: current_orbit => null() type(orblist_type) :: saved_orbits(10) contains [/fortran]

[Steven_L_Intel1]

Ok - almost three years old. I can reproduce the error with that version but not one that is slightly newer (12.0.5) or anything after that. Please upgrade. Your code is fine.

[dwwade]

Alright. Now the process of begging IT to let me use a version they haven't "approved". Yay for standardization. Thanks for the confirmation Steve.

[dwwade]

I've put in the request, but I doubt that I can get the update prior to losing my funding for this project. I'm going to reformulate my approach. If I have a top level type of each that doesn't contain that pointer, then a derived type that does, then I should be able to make it work. I could then make all of the derived types be the children that are of the top level types right now. Since we don't have direct type casting in this language, I don't think there will be an issue, as it would have to go through the Select Type construct anyway.