Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Use of TYPE or CLASS

Svein-Atle_Engeseth
649 Views
Hi everyone,
Could anyone describe the differences in using TYPE or CLASS in declarations or in SELECT TYPE statements?
Also, I can not get type bound procedures to work if I use the PASS option, only NOPASS works.
Does anyone else have the same problem?
The compiler is ifort 11.1.051.

Thanks
0 Kudos
9 Replies
joseph_battelle
Beginner
649 Views
From 8.1.5.2 of the standard:

Within the block following a TYPE IS type guard statement, the associating entity (16.4.5) is not
polymorphic (5.1.1.2), has the type named in the type guard statement, and has the type parameter
values of the selector.


Within the block following a CLASS IS type guard statement, the associating entity is polymorphic and
has the declared type named in the type guard statement. The type parameter values of the associating
entity are the corresponding type parameter values of the selector.
0 Kudos
Svein-Atle_Engeseth
649 Views
Hi,
Thanks for the answer.
I have another question regarding TYPE or CLASS.
I made a program containg the type MAALER with the extensions TERMOMETER, BAROMETER and VINDMAALER. All these types have type bound procedures. First I made them with the NOPASS attribute.
This worked well. Then I changed to PASS. To get this to work I had to change from
TYPE(TERMOMETER) to CLASS(TERMOMETER) and so on in all the procedures of the extended types.
Is this according to the standard or a bug?
The compiler is ifort 11.1.051.

The program is attached.

Regards,

0 Kudos
Steven_L_Intel1
Employee
649 Views
What went wrong when you tried it? This program compiles and runs with 11.1.065.
0 Kudos
joseph_battelle
Beginner
649 Views
4.5.3.3 The passed-object dummy argument
C453 The passed-object dummy argument shall be a scalar, nonpointer, nonallocatable dummy dataobject with the same declared type as the type being defined; all of its length type parametersshall be assumed; it shall be polymorphic (5.1.1.2) if and only if the type being defined isextensible (4.5.6).
4.5.6 Type extension
A nonsequence derived type that does not have the BIND attribute is an extensible type.
0 Kudos
joseph_battelle
Beginner
649 Views
The OP's question boils down to this:
[fortran]module M9
    type t
        real ::a
    contains
        procedure, pass(arg) :: foo
        procedure, pass(arg) :: bar
    end type t
contains
    subroutine bar(arg)
    class(t), intent(in) :: arg !OK; polymorphic
    end subroutine
    subroutine foo(arg)
    type(t), intent(in) :: arg !non-standard? ifort complains about not being polymorphic
    end subroutine
end module    [/fortran]
This example is adapted from page 97 of "The Fortran 2003 Handbook". Which shows using type(x) instead of class(x) for TBP dummies when no polymorphism is actually involved. Either the book is wrong or the compiler is wrong.
0 Kudos
abhimodak
New Contributor I
649 Views
{I think this topic may have been discussed before.}

Page 89 of the handbook gives the rules and restrictions for passed-object dummy argument. Rule 6 last line says: "It must be polymorphic (5.2) if and only if the type is extensible (4.4.12)." (I have made extensible bold.)

Section 4.4.12, page 100, paragraph 2, first line: Any derived type that is neither a sequence nor a bind type is extensible.

Hence, I think, keyword class should be used in the example on page 97.

Abhi
0 Kudos
joseph_battelle
Beginner
649 Views
Right--same rules as I posted from the standard above. I tend to agree the book is wrong. Anyways it's easy to just use class and forget about it :)
0 Kudos
Svein-Atle_Engeseth
649 Views
Hi Steve,
The attached version compiles. If you change from CLASS to TYPE in the routines SETT_TEMPERATUR, SETT_TRYKK and so on it fails on my compiler.
0 Kudos
Svein-Atle_Engeseth
649 Views
Hi Joseph,
Thanks, this is exactly the point.
Svein
0 Kudos
Reply