generic interface real function vs real
in [Fortran]
|
Prev: Can someone know the time for a oo implemented F2003 complier release under the window platform?
Next: Derived type argument to subroutine
From: mabrowning on 16 Apr 2008 18:13 I am trying to create a subroutine that can either take a time dependent function, or a constant. It compiles and runs perfectly with GNU Fortran (GCC) 4.2.3, but ifort (IFORT) 10.0 20070426 complains: fortcom: Warning: generic.f90, line 13: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [FOO_SCALAR] SUBROUTINE foo_scalar(A) -------------------^ It looks like the function signature and the scalar signature are the same? This doesn't seem to make sense! --------------------------------------------------------------------------- example: MODULE foo INTERFACE generic MODULE PROCEDURE foo_fun, foo_scalar END INTERFACE CONTAINS SUBROUTINE foo_fun(f) INTERFACE REAL FUNCTION f(t) REAL t END FUNCTION END INTERFACE WRITE(*,*)f(1.0) END SUBROUTINE SUBROUTINE foo_scalar(A) REAL A WRITE(*,*)A END SUBROUTINE END MODULE PROGRAM main USE foo REAL ::A=1.0 REAL, EXTERNAL :: f CALL generic(A) CALL generic(f) END PROGRAM REAL FUNCTION f(t) REAL t f=t END FUNCTION
From: jamesgiles on 16 Apr 2008 18:30 On Apr 16, 4:13 pm, mabrowning <mabrownin...(a)gmail.com> wrote: > I am trying to create a subroutine that can either take a time > dependent function, or a constant. ... Unfortunately, the resolution of which specific to call is based entirely and only on four criteria: 1) number of arguments, and for each of those arguments 2) type, 3) KIND, and 4) rank. In your example, both your functions accept only one argument, and that argument is REAL, default KIND, and rank zero (scalar). So, for the purposes of Fortran procedure overloading, those functions are not usefully different. -- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare
From: FX on 16 Apr 2008 18:32 > It compiles and runs perfectly with GNU Fortran (GCC) 4.2.3, but ifort > (IFORT) 10.0 20070426 complains I was going to say that this is an Intel bug, because it looked OK to me and other compilers certainly did accept it (Sun, gfortran, IBM) but Lahey also complains. So, I looked into the F2003 standard and I think that's what the last example (INTERFACE BAD9) of C.11.2 says: it is unambiguous, but still invalid, because: "the rules do not distinguish on the basis of any properties other than type, kind type parameters, and rank". Anyone willing to confirm/infirm this? PS: the root cause for that might be the will to have some simpler rules, but it is a bit sad if the example showed by the poster is invalid (moreover, these rules *are* complex anyway). -- FX
From: Richard Maine on 16 Apr 2008 18:59 FX <coudert(a)alussinan.org> wrote: > "the rules do not distinguish on > the basis of any properties other than type, kind type parameters, and > rank". > > Anyone willing to confirm/infirm this? That's correct. Thus the common abbreviation TKR (for type,kind, and rank). That combination comes up enough to merit an abbreviation. > PS: the root cause for that might be the will to have some simpler rules, > but it is a bit sad if the example showed by the poster is invalid > (moreover, these rules *are* complex anyway). Indeed the rules are complex in that area. And there must be about a dozen different proposals for enhancing the rules, including some proposals that are directly incompatible with each other. That is definitely an area where "this enhancement would be nifty" is nowhere near a good enough selling point. It takes a lot of looking at the cost/benefit, including the impact on other potential enhancements. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: Steve Lionel on 16 Apr 2008 20:52
Richard Maine wrote: > FX <coudert(a)alussinan.org> wrote: > >> "the rules do not distinguish on >> the basis of any properties other than type, kind type parameters, and >> rank". >> >> Anyone willing to confirm/infirm this? > > That's correct. Thus the common abbreviation TKR (for type,kind, and > rank). That combination comes up enough to merit an abbreviation. Right. I recall this issue very well and wrote up the problem report, since earlier versions of ifort did allow this. The key, as Richard says, is that "procedureness" (my word) is not a distinguishing factor for generic resolution. -- Steve Lionel Developer Products Division Intel Corporation Nashua, NH For email address, replace "invalid" with "com" User communities for Intel Software Development Products http://softwareforums.intel.com/ Intel Fortran Support http://support.intel.com/support/performancetools/fortran My Fortran blog http://www.intel.com/software/drfortran |