"Legal" to pass a class object to a function expecting a type object?

[thomas_boehme]

I'd like to know if it is legal to pass an object which is defined as class (A) :: Ainst to a subroutine which actually expects a type(A). Is that covered by the F2003 standard?

It seems to work as the code below works on IVF 11.1.038. Clearly, I won't have access to the fields unique to B, but I don't mind that.

The main reason why I'd like to know whether this is valid is twofold. First of all, currently, class objects are not correctly displayed in the debugger (I submitted that before). If I'd like to use member functions, I am forced to use class objects instead of types, therefore I cannot debug in member functions. Using a wrapper as a member function which in turn uses type instead of class would allow us to bypass this problem until it is solved.
Furthermore, performance test I haveperformed indicate, that there is some penalty for using a class reference instead of a type reference. With the wrapper function workaround, this penalty disappeared.

I think a"cleaner" approach would be to use a select type statement and put the call to a TYPE IS ... section, however, my performance test showed that this does add measureable overhead (actually much more than I expected, makes my simple test of adding large arrays about 6 times slower!).

Best regards,
Thomas

[plain]    module TypeDefs

    implicit none

    type :: A
    integer :: val
    contains 
        procedure Display
    end type
        
    type, extends(A) :: B
        integer :: val2
    end type

    contains
    
    subroutine Display( this )
    class (A)   :: this
        CALL DisplayA( this )
    end subroutine
        
    subroutine DisplayA( this )
    type (A)        :: this
        write (*,*) 'DisplayA: ', this%val
    end subroutine   
        
    end module TypeDefs

    program Test
    use TypeDefs

    type (B), target        ::  Binst
    
    Binst%val  = 1
    Binst%val2 = 2
        
    CALL Binst%Display

    end program Test
[/plain]

[Steven_L_Intel1 · Accepted solution]

This is legal. "A polymorphic entity that is not an unlimited polymorphic entity is type compatible with entities of the same declared type or any of its extensions."

[thomas_boehme]

Quoting - Steve Lionel (Intel)

This is legal. "A polymorphic entity that is not an unlimited polymorphic entity is type compatible with entities of the same declared type or any of its extensions."

Thanks for the quick answer.This will allow us to use this as a workaround until the debug of class objects is possible.

Could you comment on why there is an overhead when using class (A) instead of type (A) as a dummy argument in functions? Is that by design or only because it's an early version?The largest problem with that is that type-bound procedurs with PASS force you to use class even if you know that type would be fine (e.g. if every extension does override the type-bound procedure).

Best regards,
Thomas

[Steven_L_Intel1]

When you are dealing with a polymorphic item, the compiled code needs to look through passed data structures to find information about the actual type. I am not familiar with the implementation details. Perhaps this is something we will be able to improve over time.