사용자 정의 함수를 입력으로 사용하는 프로 시저를 포함하는 기본 유형이 있습니다. 사용자 정의 함수는 확장 된 유형으로 정의됩니다. 다음은 ifort-13.1.3로 컴파일하지만 gfortran-4.8.1와 함께 실패gfortran은 특정 다형성 사례와 함께 실패합니다.
이module m
implicit none
type, abstract :: base
contains
procedure :: use_f
end type base
type, extends(base) :: extended
contains
procedure :: f
procedure :: test ! calls use_f which takes f as argument
end type extended
contains
subroutine f(this)
class(extended) :: this
end subroutine f
subroutine use_f(this, func)
class(base) :: this
interface
subroutine func(this)
import :: base
class(base) :: this
end subroutine func
end interface
end subroutine use_f
subroutine test(this)
class(extended) :: this
call this%use_f(f) ! This is the important part!
end subroutine test
end module m
program a
end program a
gfortran가 나는 또한 프로 시저 포인터를 사용하여 시도했다
call this%use_f(f)
1
Error: Interface mismatch in dummy procedure 'func' at (1): Type/rank mismatch in argument 'this'
을 생산하지만, gfortran이 실패하면서 여전히 ifort은 컴파일합니다. 이제 경우 대신 인터페이스 블록의 I 코드가 ifort와 gfortran 모두 성공적으로 컴파일 use_f에
external func
을 넣어. 그러나 EXTERNAL 키워드가 시대에 뒤 떨어진 것이 아닌가? 더 표준에 부합하는 접근 방식이 효과가 있습니까?
답장을 보내 주셔서 감사합니다. 위의 예제는 실제로 'f'가 일부 '확장 된'특정 변수와 프로 시저에 액세스해야하기 때문에 지나치게 단순화 된 것 같습니다. 나는 'f'를 구속력을 갖는 것보다 다른 어떤 방법도 보지 못합니다. 또한, "polymorphic 인자가있는 프로 시저에는 명시적인 인터페이스가 있어야하므로 더미 프로 시저 인수를 사용할 수 없습니다"라는 것을 잘 모르겠다.EXTERNAL 키워드를 사용하면 'f'가 서브 루틴에서 f (this,)를 호출하여 사용되며 이는 예상대로 작동합니다. –
죄송합니다, 예제가 단순화 된 것을 잊었습니다. 나는 'f'가 서브 루틴에서 f (this)를 호출하여 사용된다고 말하고자했습니다. –
나는 바인딩과 절차가 혼란 스럽다고 생각합니다. 예제 코드는 바인딩'f'를 전혀 참조하지 않습니다. 두 가지 가능성 - use_f는 프로 시저를 인수로 사용하여 전달되는 프로 시저에 유연성을 제공합니다. 인수 대신 실제로 구현해야하는 기본 유형의 지연 바인딩입니까? 그렇지 않다면, 프로 시저'f'의 인수는 class (base) 여야하며, SELECT TYPE을 사용하여 인수를 확장 된 유형의 객체로 사용할 수 있습니다 (실제 인수가 해당 유형이라고 가정). – IanH