- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Since Class(*) is type compatible with any type, can it be used in a binding which gets overridden by a binding with specific type?
The snippet below gives compile-time error with IVF 12 update 1. (With use of Class(*) in subroutine Tech it works as expected.) I don't get an error with XLFortran but I am not 100% sure if it is right.
A similar question can also be asked for a procedure pointer component. That is, in the definition of type the interface of the procedure pointer is given Class(*) and when it is used (points to other procedure) some other type is used. (IVF 12 gives an error for this case as well.)
Abhi
------------
Since Class(*) is type compatible with any type, can it be used in a binding which gets overridden by a binding with specific type?
The snippet below gives compile-time error with IVF 12 update 1. (With use of Class(*) in subroutine Tech it works as expected.) I don't get an error with XLFortran but I am not 100% sure if it is right.
A similar question can also be asked for a procedure pointer component. That is, in the definition of type the interface of the procedure pointer is given Class(*) and when it is used (points to other procedure) some other type is used. (IVF 12 gives an error for this case as well.)
Abhi
------------
[fortran] Module OM Implicit None Private Type newBase Integer :: i Contains Procedure, NoPass :: Method Procedure :: Calculate End Type newBase Public :: newBase Contains Subroutine Method(other, n) Class(*), Intent(IN) :: other Integer, Intent(IN) :: n print *, n End Subroutine Method Subroutine Calculate(OBJ, other, n) Class(newBase), Intent(IN) :: OBJ Class(*), Intent(IN) :: other Integer, Intent(IN) :: n Call OBJ%Method(other, n) End Subroutine Calculate End Module OM Module Shree Use OM Implicit None Private Type newModel Real :: r Contains Procedure :: Compute End Type newModel Type, Extends(newBase) :: newExt Contains Procedure, NoPass :: Method => Tech End Type newExt Type(newExt) :: EXT Public :: newModel Contains Subroutine Tech(other, n) Class(newModel), Intent(IN) :: other !Class(*), Intent(IN) :: other Integer, Intent(IN) :: n Print *, n+1 End Subroutine Tech Subroutine Compute(Model) Class(newModel), Intent(IN) :: Model Integer :: m m = -1 Call EXT%Calculate(Model, m) End Subroutine Compute End Module Shree Program Test_Polymorphic Use Shree Implicit None Type(newModel) :: Model Call Model%Compute() End Program Test_Polymorphic[/fortran]
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think this is the same as a previously reported issue, ID DPD200163706. Did you really mean to say Class(newModel) and not Class(newExt)? You do the override in the declaration of newExt, so it would be incorrect to have something of type or class newModel as the "passed-object dummy argument".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve
Thanks. I should have added the reference to the post you mentioned. I had read it but perceived it to be slightly different.
Note that the procedure Method is "NoPass" and thus there is no pass-object dummy. I am overriding by passing Class(newModel) and not Class(newExt). I think that is still correct since the corresponding argument is Class(*).
Also, will it be the same case with procedure pointer component? The sample program is given below.
{The ultimate goal is to pass the type bound procedure of Model to Base. The desired usage is to allow another subroutine in Base (such as Calculate in the overriding example) to call procedures that differ only by one argument corresponding to the "class" such as newModel.}
Abhi
---
Thanks. I should have added the reference to the post you mentioned. I had read it but perceived it to be slightly different.
Note that the procedure Method is "NoPass" and thus there is no pass-object dummy. I am overriding by passing Class(newModel) and not Class(newExt). I think that is still correct since the corresponding argument is Class(*).
Also, will it be the same case with procedure pointer component? The sample program is given below.
{The ultimate goal is to pass the type bound procedure of Model to Base. The desired usage is to allow another subroutine in Base (such as Calculate in the overriding example) to call procedures that differ only by one argument corresponding to the "class" such as newModel.}
Abhi
---
[fortran] Module OM Implicit None Type newBase Integer :: i Procedure(FUN), Pointer, NoPass :: Method End Type newBase Abstract Interface Subroutine FUN(OBJ, n) Class(*), Intent(IN) :: OBJ Integer, Intent(IN) :: n End Subroutine FUN End Interface End Module OM Module Shree Use OM Implicit None Type newModel Real :: r Contains Procedure :: Compute Procedure :: Tech End Type newModel Contains Subroutine Compute(Model) Class(newModel), Intent(INOUT) :: Model Integer :: m Type(newBase) :: Base Base%Method => Tech End Subroutine Compute Subroutine Tech(Model, j) Class(newModel), Intent(INOUT) :: Model !Class(*), Intent(INOUT) :: Model Integer, Intent(IN) :: j End Subroutine Tech End Module Shree Program Test_ProcedurePointer Use Shree Implicit None End Program Test_ProcedurePointer [/fortran]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ah, I had missed that. The standard requires that all dummy arguments of the overriding and overridden procedures, other than the passed-object, match in name and characteristics, including type.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The problem with compiling the first code shown in this thread has been fixed in 12.0 Update 3. The second code is incorrect.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We've been looking at this issue again. While it is true that class(*) is type-compatible with any type, that doesn't mean it is "the same as" any other type. Indeed, the standard says that entities of class(*) have no type at all. In the context of overrides, if one of the dummies is class(*) they all must be. We're going to correct the compiler to give an error where this is not the case.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page