Structure versus TYPE

[holmz]

I stumbled upon this a couple of weeks ago...

I have a lot of reused code (via INCLUDE) which uses the STRUCTURE and then RECORD in the routines. I am not aware that RECORD can make use of the INTENT() argument, so I prefer to use TYPE.
While modifying some code I declared it as STRUCTURE in the subroutine and used TYPE to reference the STRUCTURE. I was not really intending to that, but when it compiled and ran it got me thinking...

Is it intended and OK to make use of the STRUCTURE and reference those using TYPE? It is certainly handy to be able to not have to change the INCLUDEd files, but be able to use INTENT.

Code looks like:

      PROGRAM XX
      IMPLICIT NONE
!<Old Code>
      STRUCTURE POSITION
        REAL(KIND=8) :: X, Y, Z 
      END STRUCTURE
      RECORD /POSITION/  Here, There

!<New Code>
!TYPE POSITION_TYPE
!  REAL(KIND=8) :: X
!  REAL(KIND=8) :: Y 
!  REAL(KIND=8) :: Z
!END TYPE POSITION_TYPE
!      TYPE(Position_Type) :: Here
!      TYPE(Position_Type) :: There

      CALL XXX(Here, There, Distance)

      END PROGRAM XX

      SUBROUTINE XXX (Here, There, Distance)
!      <Old Code>
      STRUCTURE POSITION
        REAL(KIND=8) :: X, Y, Z 
      END STRUCTURE
      RECORD /POSITION/  Here, There

      TYPE(POSITION), INTENT(IN   ) :: Here
      TYPE(POSITION), INTENT(IN   ) :: There
      TYPE(POSITION), INTENT(  OUT) :: Distance
      Distance = ( 
     &      (Here%X - There%X)**2 +
     &      (Here%Y - There%Y)**2 +
     &      (Here%Z - There%Z)**2    )**0.5

      END SUBROUTINE XXX

[mecej4]

STRUCTURE, RECORD, etc., are nonstandard extensions. These extensions provided capabilities that were lacking in standard Fortran 77, but Fortran 90 and later versions provide other ways (such as user-defined types) of achieving the same ends. My suggestion is to do away with the extensions. You have to decide the rate at which you do the code upgrade based on your project requirements and constraints. Even if you decide to continue using the nonstandard extensions, mixing them with features of Fortran 90+, such as specifying INTENT for RECORD variables, passing them as OPTIONAL arguments, etc., is something to avoid.

[jimdempseyatthecove]

You will likely also have issues with interfaces as TYPE, RECORD, STRUCTURE will likely get flagged as not conforming to the interface.

There may also be some rules as to if each does or does not naturally align members and/or rearrange members to meet naturally alignment. For TYPE you may need to add SEQUENCE to assure compatibility with RECORD.

Jim Dempsey

[Steven_L_Intel1 · Accepted solution]

Most of the time, Intel Fortran treats STRUCTURE/RECORD and derived types as interchangeable. There are some corner cases where it doesn't, but I don't remember what they are offhand. My advice is to avoid STRUCTURE/.RECORD unless you also need to use UNION/MAP.

[holmz]

Steve Lionel (Intel) wrote:

Most of the time, Intel Fortran treats STRUCTURE/RECORD and derived types as interchangeable. There are some corner cases where it doesn't, but I don't remember what they are offhand. My advice is to avoid STRUCTURE/.RECORD unless you also need to use UNION/MAP.

Bingo!  UNION and MAP are in a lot of these legacy structures. 

Knowing that ifort uses them interchangeably is good, as it allow me to use INTENT to help make the code easier to follow.

Thanks,

Randal
 

jimdempseyatthecove wrote:
 You will likely also have issues with interfaces as TYPE, RECORD, STRUCTURE will likely get flagged as not conforming to the interface.

I was actually an eyebrow raiser to see that there were no warnings. That followed by it working then resulted in some beard-stroking, think and wondering if it was safe to take advantage of that. So Steve's post made sense.

jimdempseyatthecove wrote:
There may also be some rules as to if each does or does not naturally align members and/or rearrange members to meet naturally alignment. For TYPE you may need to add SEQUENCE to assure compatibility with RECORD.

Jim Dempsey

Ok - Thats Jim - I need to look at SEQUENCE. It always amazes me when I find new things.

I generally am using -noalign for a lot of structures/records that get output directly to files. In the libraries I often use -align in the hope that it aids with the speed.

[jimdempseyatthecove]

Steve,

I use UNIONs inside TYPE. It is quite handy when your are reading files where you don't know what you have until after you read it.

Jim Dempsey

[Steven_L_Intel1]

I'm conflicted about our allowing UNION/MAP within TYPE (as opposed to STRUCTURE). I don't for a moment doubt the usefulness of UNION, but it makes me uneasy to mix the features that way - there might be some unexpected interaction with the standard language (BIND? SEQUENCE? Type parameters or type-bound procedures?)

[jimdempseyatthecove]

On the TYPE's with UNION, I always use SEQUENCE.

Jim Dempsey

[JVanB]

My recollection is that DirectX had structures that were simply rotten with unions and that UNION+BIND(C) would be about the only way you could write out interfaces. VARYING+BIND(C) would be nice (not for actual procedures, but for interface bodies) to interface with ObjectiveC.