Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs have moved to the Altera Community. Existing Intel Community members can sign in with their current credentials.

Circular class reference allowed?

dwwade
Beginner
1,216 Views

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

0 Kudos
5 Replies
Steven_L_Intel1
Employee
1,216 Views
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?
0 Kudos
dwwade
Beginner
1,216 Views
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]
0 Kudos
Steven_L_Intel1
Employee
1,216 Views
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.
0 Kudos
dwwade
Beginner
1,216 Views
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.
0 Kudos
dwwade
Beginner
1,216 Views
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.
0 Kudos
Reply