- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
ifort does not compile the following code because:
ifort -c m.f90
m.f90(15): error #8423: In GENERIC type bound procedure definition each binding name must be the name of a specific binding of the type. [FF]
generic :: gen_f => ff
----------------------^
compilation aborted for m.f90 (code 1)
I wander whether this error is correct, since I would expect the
procedure ff to be equally available in t1 and t2 - but I must say
that I don't know what the standard says about this.
ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0 Build 20140120
module m
implicit none
private
type, abstract :: t1
contains
!generic :: gen_f => ff ! works
procedure, pass(this) :: ff
end type t1
type, abstract, extends(t1) :: t2
contains
generic :: gen_f => ff ! does not work
end type t2
contains
subroutine ff(this)
class(t1) :: this
! do nothing
end subroutine ff
end module m
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am inclined to agree with you that this code is legal. I will pass this on to the developers and let you know of any progress. Issue ID is DPD200256336.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't know if such a thing is allowed by the standard, but gfortran 4.9 allows it.
But it doesn't "feel right" to do something like this though - I'd personally shy away from it in my code as I'd greatly struggle trying to understand it if I've to revisit it at any later stage. This is especially the case since the standard grants the facility to add to a generic in extended types.
What is your use case for this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve, than you for checking.
FortranFan: I think that classes are built on top of each other very much like modules, so generic procedures have the same pros and cons: sometimes they help and sometimes (often?) they hide useful information.
In my small example, the net effect is making ff available also under the name gen_f. A more complicated case would be a base class with a constructor which must be overloaded for a derived class.
Marco
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Marco wrote:
.. classes are built on top of each other very much like modules, so generic procedures have the same pros and cons: sometimes they help and sometimes (often?) they hide useful information.
In my small example, the net effect is making ff available also under the name gen_f. A more complicated case would be a base class with a constructor which must be overloaded for a derived class.
..
No, I find generics to be very helpful and use them all the time - there are hardly any cons with them in my book.
Instead I was referring to your specific approach of binding a procedure "contained" in a "base" derived type to a generic that gets specified only in an extended type. In your example above, why can't you simply do as follows?
MODULE m IMPLICIT NONE PRIVATE TYPE, ABSTRACT :: t1 CONTAINS GENERIC :: gen_f => ff PROCEDURE, PASS(this) :: ff END TYPE t1 TYPE, ABSTRACT, EXTENDS(t1) :: t2 END TYPE t2 CONTAINS SUBROUTINE ff(this) CLASS(t1) :: this !.. Do nothing END SUBROUTINE ff END MODULE m
Then, as I mentioned above, if you need to "extend" gen_f to cover other procedures contained in extended derived types, you can repeat generic :: gen_f => .. statements in those extended types.
So what I've is a design question: why you don't want the base definition of gen_f generic to be specified in t1 itself when ff is contained in there; why place it in t2? That is, is there some advantage I'm not aware of?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Instead I was referring to your specific approach of binding a procedure "contained" in a "base" derived type to a generic that gets specified only in an extended type. In your example above, why can't you simply do as follows?
Yes, putting it in the base class would be a perfectly fine option, I agree. The point is, sometimes you can not change the base class, or sometimes the generic only makes sense in the extended class, so in these cases I see nothing bad defining it in the extended class. This also happens with module procedure: sometimes a module uses another one and overloads a subroutine, making it a generic one.

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