module mod_m
implicit none
public :: &
t_a, &
!t_b, &
operator(+)
private
type t_a
integer :: a
end type t_a
type t_b
real :: b
end type t_b
interface operator(+)
module procedure add_t_a, add_t_b
end interface
contains
pure function add_t_a(a1,a2) result(a)
type(t_a) :: a
type(t_a), intent(in) :: a1, a2
a%a = a1%a+a2%a
end function add_t_a
pure function add_t_b(b1,b2) result(b)
type(t_b) :: b
type(t_b), intent(in) :: b1, b2
b%b = b1%b+b2%b
end function add_t_b
end module mod_m
Now: gfortran and g95 compile the code, while ifort complains that
fortcom: Error: fquest.f90, line 33: The function result of this
module procedure is of a type that has PRIVATE accessibility and has a
generic identifier that has PUBLIC accessiblity. [ADD_T_B]
pure function add_t_b(b1,b2) result(b)
---------------^
fortcom: Error: fquest.f90, line 33: This dummy argument of this
module procedure is of a type that has PRIVATE accessibility and the
procedure has a generic identifier that has PUBLIC accessiblity.
[B1]
pure function add_t_b(b1,b2) result(b)
-----------------------^
fortcom: Error: fquest.f90, line 33: This dummy argument of this
module procedure is of a type that has PRIVATE accessibility and the
procedure has a generic identifier that has PUBLIC accessiblity.
[B2]
pure function add_t_b(b1,b2) result(b)
--------------------------^
Who is right?
GNU Fortran (GCC) 4.3.0 20071122 (experimental) [trunk revision
130342]
G95 (GCC 4.1.1 (g95 0.91!) Aug 20 2007)
ifort (IFORT) 10.1 20080212
Thank you,
Marco
> fortcom: Error: fquest.f90, line 33: This dummy argument of this
> module procedure is of a type that has PRIVATE accessibility and the
> procedure has a generic identifier that has PUBLIC accessiblity.
There were a bunch of restrictions like this that were removed with one
of the Fortran revisions. I think it was between f95 and f2003. So in
some sense, both compilers are right. You might want to look at the
particular compiler options for controlling the version of the standard
that messages are produced for; some compilers have multiple options
there.
It is my opinion that these restrictions were misguided in the first
place. They achieved nothing useful and disallowed otherwise reasonable
coding practices. I think that a majority of J3 eventually came to agree
with that. AT any case, they did agree with removing the restrictions in
f2003.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
>You might want to look at the
>particular compiler options for controlling the version of the standard
>that messages are produced for; some compilers have multiple options
>there.
Unfortunately this won't help with ifort. I'll make sure that this is brought
to the attention of the appropriate folk.
--
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