다른 파일에있는 OOP 포트란, 유형 및 절차

Question

실제 서브 루틴을 유형 바인드 프로 시저 및 유형 정의 뒤에 다른 파일에 둘 수 있는지 궁금합니다. EG :

파일 A :

Module TypeDef 
Type :: Test 
    Integer :: a,b,c 
contains 
    Procedure, Pass, Public :: add => SubAdd 
End Type 
Type(Test) :: Test 
    Interface 
    Subroutine SubAdd(this) 
     Import TypeDef 
     Class(TypeDef), Intent(InOut) :: this 
    End Subroutine 
    End Interface 
End Module 

파일 B :

: 첫 번째 다음 파일 B 파일을 컴파일 할 때, ifort 오류 메시지를 제공하기 때문에

Module TypeRoutines 
    use TypeDef 
    Private :: SubAdd 
contains 
    Subroutine SubAdd(this) 
     Class(TypeDef), Intent(InOut) :: this 
     this%c=this%a+this%b 
    End Subroutine 
End Module 

이 작동하지 않습니다

The name of the module procedure conflicts with a name in the encompassing scoping unit 

이것이 주된 이유는 어떤 유형의 경우 많은 유형의 바운드 프로 시저를 작성해야한다는 것입니다 몇 가지 파일이 수백 줄에 걸쳐 확장되어 작업이 매우 지루합니다. 궁극적 인 목표는 모든 단일 서브 루틴을 다른 파일에 배치하는 것입니다.

아이디어가 있으십니까?

Answer 1

당신의 바인딩이 전달 된 인자를 가지고 있다고 가정 (그렇지 않으면 일이 쉽게) :

쉬운! 프로 시저 본문을 TypeDef 모듈의 서브 모듈에 놓고 프로 시저의 인터페이스를 모듈 자체의 스펙 부분에있는 별도의 인터페이스 본문으로 복사 및 편집하십시오. 유일한 히치 (서브 모듈을 지원 한) 그것은 F2008 컴파일러를 필요로하고 현재 ifort 그 중 하나가 아닙니다 ... 당신은 다음과 같은 옵션이 생각하는 현실 세계에서

:

을
• 바인딩은 명시 적 인터페이스가있는 외부 프로 시저 일 수 있습니다 ... 특정 바인딩을 구현하는 각 프로 시저를 외부 프로 시저 (사용자가 시도한 모듈 프로 시저가 아님)로 만들고, 외부 프로 시저마다 인터페이스 본문을 모듈을 완성한 다음 각 바인딩을 해당 외부 프로 시저와 연관시킵니다. 인터페이스 유형이 외부 프로 시저의 실제 인터페이스와 일치하는지 확인하기 위해 외부 프로 시저가 액세스하고주의해야하는 개인 구성 요소 또는 바인딩이 유형에있는 경우이 접근법은 실패합니다.

또는

• 는 별도의 파일에 각 모듈의 절차를 넣어, 그리고 모듈의 문을 포함 한 후 다음 해당 별도의 파일이 포함됩니다.

또는 큰 파일과 라이브

• .