나는 FORTRAN을 많이 사용하지만, 소스 코드를 작성하는 적절한 방법으로 정식 명령을 한 적이 없었습니다. 현재 모듈을 사용하여 전역 변수를 저장하고 있지만 서브 루틴 및 함수를 저장하는데도 사용할 수 있음을 알고 있습니다. 코드는 매우 크고 복잡하기 때문에 많은 서브 루틴을 가지고 있습니다. 모든 함수와 서브 루틴이 모듈에 있어야합니까? 그렇다면 왜?Fortran에서 모듈을 올바르게 사용하기
일반적으로 첫 번째 질문에 대한 대답은 예이며 잠시 후 두 번째 질문에 대한 답변을 드리겠습니다. 우선 이것은 일반적인 질문에 대한 일반적인 대답이며 SO Fortran 질문에 매달려있는 밝은 불꽃은 모듈이 적용 할 수없는 특수한 상황이 발생할 수 있습니다. 나는이 대답이 모듈을 처음 접하는 사람들을 대상으로한다는 것을 사전에 말하지 않았다. 더 이상 신참이 아니게되면 자신의 질문에 대한 답을 공식화 할 수 있습니다.
모듈은 프로그램이나 프로그램 모음을 구성하고 구조화하는 데 도움이되는 프로그래머에게 가장 유용합니다. 이들은 사용자 정의 유형 및 해당 유형에서 작동하는 함수/서브 루틴의 정의를 캡슐 화하기위한 메커니즘을 제공합니다. 포트란 90과 95에서이 캡슐화는 프로그램을 부분으로 분해하는 방법에 대한 프로그래머의 아이디어에 의존한다는 점에서 다소 임시적인 것이었다. Fortran 2003에 객체 지향 기능이 도입됨에 따라 각 모듈에 속한 요소를 식별하기위한보다 명확한 '규칙'이 추가되었습니다.
예를 들어, 합리적인 산술을위한 유형 및 프로 시저에 대해 모듈을 생각할 수 있습니다. 훌륭한 아이디어를 구현하는 모든 코드를 하나의 모듈에 보관하면 프로그램의 다른 부분 (구현 세부 정보는 알 필요가 없음)에서 구현을 숨기고 노출하려는 부분 만 노출 할 수 있습니다 (PRIVATE 및 PUBLIC 참조). 키워드). 지금 당장 코드를 모듈로 구성하는 또 다른 이점을 확인할 수 있습니다. 메가 소스 파일의 코드를 잘라내어 다른 메가 소스 파일로 옮기는 것보다 새로운 프로그램에서 합리적인 산술 모듈 USE을 사용하는 것이 훨씬 쉽습니다. 합리적인 산술 연산을 원할 때 파일 전체에 코드가 분산되어있는 것이 아니라 한 모듈에서 코드를 처리합니다.
모듈을 사용하면 이름 충돌을 관리 할 수도 있습니다. 예를 들어 합리적인 산술 모듈은 add이라는 연산을 정의 할 수 있으며 add이라는 연산을 정의하는 다중 정밀도 정수 산술 연산 모듈을 사용할 수도 있습니다. USE 프로그램 (또는 다른 모듈)에서 이러한 모듈을 모두 시도하면 컴파일러는 동일한 이름이 모듈을 사용하는 범위 내에서 두 번 정의된다는 경고를 표시합니다 (오류 발생 가능성 있음). 연관 모듈 엔티티를 사용할 때 이름 바꾸기를 사용할 수 있습니다. ONLY 절을 사용하여 사용자가 필요로하는 모듈 엔티티 만 가져올 수도 있습니다.
모듈 USE은 A가 B를 사용하고 B가 C를 사용하는 경우 A가 C를 사용한다고 선언 할 필요가 없습니다 (단, 엔티티의 이름을 변경했거나 ONLY 절을 지정했는지 확인해야 함). 어떤 경우에는 전 이적입니다).
간단히 말해서, 모듈은 프로그램의 복잡성을 관리 가능한 청크로 나누어 처리하는 주요 Fortran 메커니즘입니다. 기능이 컴파일러에 의해 구현 된 Fortran 2008은 SUBMODULE도 도입했는데, 이렇게하면 복잡성을 더 잘 지원할 수 있습니다.
모듈은 컴파일 타임에 컴파일러가 인수에 대해 유형 검사를 위해 모듈에 정의 된 프로 시저에 대한 명시 적 인터페이스를 생성해야한다는 점에서 유용합니다. 이러한 인터페이스 (실제로는 볼 수없는)는 모듈 내부에서 정의되지 않은 프로 시저 (또는이를 사용하는 프로그램 단위 내에서 CONTAIN에있는 프로 시저)가 갖는 암시 적 인터페이스와 대비되도록 명시 적으로 호출됩니다. 물론 이러한 프로 시저에 대한 명시 적 인터페이스를 작성할 수는 있지만 컴파일러가 수행 할 수 있도록하기 위해 거의 항상 짧고 긴 실행이 더 쉽습니다.
@Telgin이 이미 언급했듯이 모듈은 점진적 컴파일에 도움이됩니다.
모듈이 증분 컴파일을 돕는 방법을 모르겠습니다. 사실 (필자가 우려하는 한) 컴파일 두통은 모듈 사용에 대한 최선의 논거입니다. (나는 컴파일하기가 더 어렵 기 때문에 모듈을 없애라고 맹세하지는 않는다. 단지 그들이 어떻게 도움이되는지 전혀 모르겠다.) – mgilson
일반적으로 모듈을 이미 컴파일했고, 연결을 시도 할 때'.o'와'.mod' 파일이 존재하고 올바른 타임 스탬프를 가지고 있다면 Makefile은 파일을 다시 컴파일하지 않습니다. 인터페이스가 변경되지 않았지만 모듈이 수정 될 때 발생하는 * Fortran 컴파일 캐스케이드 *에 대해 알고 있습니다. –
그러나 컴파일 된'.o'가 이미 올바른 타임 스탬프와 함께 존재한다면, 그것 역시 (모듈과는 무관하게) 작동합니다. 모듈은 컴파일 순서를 지정하지 않으면 모듈이 컴파일되지 않고 모듈을 컴파일하면 2 개의 파일이 생성되는데, 이는 슬프게도'make '가 완전히 잊어 버린 것 같은 상황입니다. 그러나 다시 말하지만, 모듈을 사용하여 얻을 수있는 성능과 안전성에 대해 비용을 지불하는 것은 작은 가격이라고 생각합니다. – mgilson
관련 함수, 서브 루틴 및 변수를 자체 모듈로 이동하면 프로그램 유지 관리가 향상됩니다. 나중에 그 중 일부를 업데이트해야하는 경우 수십 (또는 수백) 줄의 코드가 포함 된 단일 소스 파일을 파고 들지 않아도 관련 파일을 열 수 있습니다.
물론, 관련 서브 루틴을 찾기 위해 편집기의 검색 기능을 사용할 수 있다고 생각할 수도 있지만, 코드를 혼자 앉아있게 한 지 몇 달이 지난 후에는 서브 루틴의 이름이나 그 서브 루틴이 어떻게 어울리는지를 떠올려보십시오. 그룹화가 잘되어 있으면 많은 도움이됩니다.
모듈로 서브 루틴과 함수를 이동하면 컴파일러가 전체 프로그램 대신 단일 모듈 만 다시 작성하면 컴파일 속도가 향상됩니다.
모듈 사용의 주요 이점 중 하나는 컴파일러가 적절한 매개 변수 유형을 사용하여 루틴을 호출하는지 확인하기 위해 모듈의 모든 기능 또는 서브 루틴에 대한 인터페이스 검사를 자동으로 수행한다는 것입니다. 이 주제에 대한 좋은 기사는 Doctor Fortran Gets Explicit - Again!입니다. 이 기사의 내용 :
명시 적 인터페이스를 제공하는 데는 여러 가지 방법이 있습니다. 가장 간단하고 가장 좋은 방법은 프로 시저를 모듈에 넣거나 호출하는 프로그램이나 프로 시저의 CONTAINed 프로 시저로 만드는 것입니다. 이렇게하면 정보를 두 번 쓰지 않아도되므로 장소 중 하나에서 정보가 잘못 표시 될 가능성이 높아집니다. 모듈 프로 시저 또는 포함 된 프로 시저가 있으면 해당 인터페이스는 모듈의 다른 모든 항목이나 상위 범위에서 자동으로 볼 수 있습니다. 이름이 PRIVATE로 선언되지 않았다고 가정하면 모듈 프로 시저가 포함 된 모듈을 사용하는 곳에서도 인터페이스를 사용할 수 있습니다.
모든 관련 루틴을 동일한 모듈에 넣는 것이 좋습니다. 모듈은 다른 언어의 클래스와 동등합니다. 모듈은 관련 데이터 및 루틴 (해당 데이터에서 작동 할 수 있음)을 그룹화하는 방법입니다. 따라서 모듈은 루틴을 논리적으로 모듈로 그룹화하고 함수 및 서브 루틴 호출에 유형 검사를 추가하면 코드를보다 쉽게 탐색 할 수있는 방법을 제공합니다.
모듈은 명시 적 인터페이스를 자동으로 제공하여 포트란 프로그램을 도와줍니다 (이미 다른 답변에서 설명한대로). 이것은 컴파일러가 많은 실수를 잡는 프로 시저 호출과 프로 시저 선언에서 인수 사이의 일관성을 검사 할 수있게 해줍니다 - 여기에 모듈의 이점을 보여주는 Stackoverflow 대답이 있습니다 : Computing the cross product of two vectors in Fortran 90, FORTRAN functions 및 Fortran segmentation fault in pointer array
아주 좋은 토론과 도움이됩니다. 내 프로그램을 구조화하는 데있어 앞으로의 일들을 염두에 두겠습니다. – rks171
은 귀하의 질문이 광범위하더라도 동의하지만 아래의 응답에 대한 훌륭한 촉매 역할을합니다. +1 – JonnyB