Derived Type Variables

[Robert]

The % sign separates the components of a derived type variable. For example: ! The following the syntax given in the language reference. george%age = 56 george%height = 6.0 But I see some examples where a period is used instead of the % sign. ! The following works too george.age = 56 george.height = 6.0 Is the use of a period in place of % considered standard FORTRAN, or is it non-standard? I am asking in case I try to compile the source with a different compiler someday. Thanks for responding.

[Robert]

The % sign separates the components of a derived type variable. For example: ! The following the syntax given in the language reference. george%age = 56 george%height = 6.0 But I see some examples where a period is used instead of the % sign. ! The following works too george.age = 56 george.height = 6.0 Is the use of a period in place of % considered standard FORTRAN, or is it non-standard? I am asking in case I try to compile the source with a different compiler someday. Thanks for responding.

[IanH]

The use of a period in that context is a non-standard extension.  Its use potentially introduces a syntax ambiguity distinguishing user defined operators from nested object part references.  Other compilers are likely to complain.

Don't go there.

[FortranFan]

Robert M. wrote:

The % sign separates the components of a derived type variable. For example:

! The following the syntax given in the language reference.
george%age = 56
george%height = 6.0

But I see some examples where a period is used instead of the % sign.

! The following works too
george.age = 56
george.height = 6.0

Is the use of a period in place of % considered standard FORTRAN, or is it non-standard? I am asking in case I try to compile the source with a different compiler someday. Thanks for responding.

You may want to look into the /stand compiler option and always apply it with your code to get flagged for any-standard extensions that are used - see here for online documentation: https://software.intel.com/en-us/node/525133.

Intel Fortran will correctly flag the use of period instead of the % delimiter as non-standard.  

[Steven_L_Intel1]

Use of the period comes from VAX Fortran's STRUCTURE/RECORD extension dating to 1985. This was before Fortran 90 had settled down and our (DEC's) customers were demanding some sort of structured data type. We picked syntax that we hoped would be distinguishable from what eventually got standardized, and in most cases we did, but we didn't count on user-defined operators. In any case, The DEC compilers (and their successors) generally treat derived types and STRUCTURE/RECORD syntax as interchangeable, down to the choice between . and %.

That said, I agree completely with Ian - use the standard syntax in new code. As you found, the period syntax has a lot of fans and is widespread, but it's never a good idea to use extensions when standard syntax exists.

[dboggs]

I myself had trouble with this issue and started a discussion chain on this forum a year or two ago. I was using the dot syntax because that's what had been used (as an extension) in much much older Microsoft v6 F77. In addition, the dot syntax is used in almost every other language, so most everyone knows what it means. In addition, it is easier to type, easier to read, and easier to talk about than the "percent" syntax. But eventually I came around. As I now continue to work on programs I last touched a year ago, I am changing all the Dave.Waistsize occurrences to Dave%Waistsize. Unfortunately it is still hard to refrain from saying "Dave dot Waistsize" when talking to someone.

In addition to the possible conflicts with user defined operators mentioned by Steve, I believe there is a possible (though rare and contrived) conflict with (the older form of) relational operators such as .EQ., .LT. etc.

[Steven_L_Intel1]

True - but we had a heuristic to deal with such conflicts - if the thing on the left was a structure that had a component named EQ, then .EQ. was that component. In F77 there was no such thing as logical operators on structures (nor structures!) With F90 and user-defined operators, we needed to turn that around a bit. This conflict is also why we have /assume:[no]old_xor, since we defined .xor. as an operator as an extension.

[Robert]

Thank you all very much for the helpful replies.