View previous topic :: View next topic |
Author |
Message |
j clark
Joined: 29 Mar 2008 Posts: 20 Location: Bala Cynwyd (Pennsylvania)
|
Posted: Fri Feb 26, 2016 3:31 pm Post subject: Derived Type Problem |
|
|
I have discovered a problem with TYPEs in FTN95 version 7.10. In the following code,
TYPE NOTSOGOOD
CHARACTER*2 CHARS
INTEGER*4 NUMBER
END TYPE NOTSOGOOD
TYPE (NOTSOGOOD) NSG(50)
when one references NSG(1)%CHARS, for example, it pick up 4 bytes: CHARS and the 2 low-order bytes of NUMBER. NSG(1)%NUMBER will contain the high-order bytes in the low-order position and NSG(2)%CHARS in the high-order bytes. NSG(2)%CHARS will contain the entire NSG(2)%NUMBER, and so on.
If I "constrain" the array with the following equivalent code:
TYPE THISWORKS
UNION
MAP
CHARACTER*6 NOTUSED
END MAP
MAP
CHARACTER*2 CHARS
INTEGER*4 NUMBER
END MAP
END UNION
TYPE (THISWORKS) TW(50)
memory is allocated and referenced correctly. There is no problem with TYPEs that contain only numeric or only character fields. They can be mixed, INTEGER*2 and REAL, for example. It's been awhile since I've looked at the forum or made a post so has anyone else discovered this or is it fixed in 7.20? |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Mar 04, 2016 4:26 pm Post subject: |
|
|
If you do not specify the keyword SEQUENCE in your TYPE, then you cannot guarantee the "arrangement" of the data in the derived TYPE. It is in the standard to require this keyword to maintain "ordering". Otherwise, the compiler can choose whatever ordering it wishes.
This is especially troublesome when passing data to/from other routines. Withing a single routine, the data should always be consistent, regardless of how they are actually "arranged".
All of my derived TYPEs now contain the keyword SEQUENCE. Even if I use them "locally".
Lesson learned the hard way... |
|
Back to top |
|
|
j clark
Joined: 29 Mar 2008 Posts: 20 Location: Bala Cynwyd (Pennsylvania)
|
Posted: Mon Mar 07, 2016 5:28 pm Post subject: |
|
|
Thank you. What I don't know about Fortran 95 would fill a book. But, hey, ask me anything about Fortran IV. |
|
Back to top |
|
|
|