4

私はgfortranの95以上の拡張機能を使用しています。他のプロジェクトにリンクしたいユーティリティモジュールのライブラリがあります。つまり、ライブラリまたは共有オブジェクト/dllとしてです。ただし、Fortranでは、モジュールインターフェイスの2つのコピーを維持せずに、Fortranの実装からインターフェイスを分割する方法がわかりません。

Cでは、次のようにインターフェイスを実装から分離します。

 api.h ←includes← impl.h
   ↑                 ↑
includes          includes
   ↑                 ↑
 user.c           impl.c

最新のFortranで同じ効果を達成する方法はありますか？ライブラリに.modファイルをユーザーに提供する必要がありますか？

  • 明示的なインターフェースの単一の定義
  • インターフェイス定義のみがユーザーコードに公開されます

編集:(私が思うに）答えを要約すると：

  • 明示的なインターフェイス定義が含まれているため、.modファイルが必要です

  • モジュール用の標準​​のFortranABIはありません-.modファイルはコンパイラ固有になります

  • 実装を隠す問題への唯一の直接的な類似のアプローチは、Fortran 2008で定義され、gfortranがサポートしていないサブモジュールです。

  • @ High-Performance-MarkとFedoraページで示されているように、モジュールを回避する以外の最も実用的なアプローチは、実装用にプリコンパイルされた.modとともに、インターフェイスのみのモジュールのインクルードファイルを配布することです。

  • インクルードを使用すると、一般的なブロックの再定義の可能性など、よく知られた厄介なトリップアップが発生します。

ここに実際に簡単な答えがないことに少し驚いています。

4

3 に答える 3

5

Fortran 2008 コンパイラを使用するサブモジュールでこれを実行できると思います。FortranWiki から:

サブモジュールは Fortran 2008 の機能で、モジュール プロシージャのインターフェイスをモジュールで定義し、プロシージャの本体を別のユニットであるサブモジュールで定義できるようにします。

ウィキペディアから（強調鉱山）

[サブモジュールを使用すると、モジュールの仕様と実装を個別のプログラム単位で表現できます。これにより、大規模なライブラリのパッケージ化が改善され、最終的なインターフェイスを公開しながら企業秘密を保護でき、コンパイルのカスケードが防止されます。

私はサブモジュールの経験がなく、まだ広くサポートされていませんが、注意が必要です。

編集多くのコンパイラはサブモジュールをサポートしていないため、他のオプションについて議論することはおそらく役に立ちます。

このページはこれと同様の質問をしており、多くの素敵なリンクがあります. Google グループに関するディスカッションで特に役立ちます (特に、この投稿を参照してください)。要約すると、1 つのオプションは次のとおりです。

  • すべてのライブラリ関数/サブルーチンを 1 つのファイルにグループ化し、それ自体でグループ化します (つまり、モジュールの一部ではありません)。

  • エンド ユーザーに公開するサブルーチンのインターフェイスのみを含むモジュールを作成します。

  • コンパイルされたモジュールとライブラリをエンド ユーザーに提供します。その後、ユーザーはuse自分のプログラムでモジュールを使用し、ライブラリにリンクできます。

これにより、エンド ユーザーに公開したくない関数/サブルーチンを「非表示」にすることができます。

私がリンクしている投稿から持ち上げた：

一部のコンパイラは、.mod (またはコンパイラが付けた名前) ファイルとライブラリ ファイルを生成します。.mod ファイルにはシンボルがあります。ライブラリ ファイルには、モジュールに含まれる実行可能コードが含まれています。この場合、両方のファイルをエンド ユーザーに配布する必要があります。

また、一部のコンパイラ (特に f95) は、シンボルと実行可能コードを単一の .mod ファイルに入れます。この場合、.mod ファイルをエンド ユーザーに提供するだけで済みます。

(最終!) 編集Fedora wiki に便利なページがあります:

理想的には、移植可能な Fortran ライブラリはモジュールの使用を避けるでしょう。良いニュースは、サブモジュール仕様が定義されていることです。これにより、モジュールのインターフェイス仕様部分をプロシージャ ソース コードから分離できるようになります。これが Fortran コンパイラに実装されている場合は、すべてのパッケージ ライブラリで使用する必要があります。

于 2012-05-31T13:39:16.697 に答える
2

それはあなたが何をしたいかによります。企業秘密のために人々からコードを隠すことが意図されている場合は、実際のコードではなく、「インターフェース」を記述して、コンパイル済みのライブラリを提供することができます。ユーザーは、プロシージャーを呼び出すことができるように、インターフェースを使用してファイルをコンパイルします。

必要なものだけを公開する優れたプログラミング プラクティスを実践したいだけの場合は、モジュールを使用し、一部のプロシージャまたはモジュール変数を "プライベート" に指定して、モジュールの内部に指定することができます。エディタでコードを見ることはできますが、モジュールの外部でプロシージャを呼び出すことはできません。プログラムの残りの部分に対しては、使用されるはずの手順のみを公開し、他の手順は非表示にすることができます。モジュールの先頭にあるプライベート ステートメントを使用して "private" をデフォルトにし、"public" ステートメントで表示する必要があるプロシージャを指定できます。

ユーザーにソース コードを見せたり、コンパイルさせたりしたくない場合を除き、私は .mod ファイルを提供しません。そのため、単にソース コードを提供するのではなく、さまざまなコンパイラをサポートするという問題が生じます。"private" ステートメントと "public" ステートメントは、インターフェイス定義を複製せず、公開したいインターフェイスのみを公開するという 2 つの目標を達成する必要があります。プログラムが非常に大きいか、他の問題がない限り、他のアプローチは非常に複雑に思えます。

于 2012-05-31T16:00:39.140 に答える
2

インターフェイスを実装から分離し、それぞれを 1 回だけ記述するための別のアプローチとして、FORTRAN77 以降 (そしておそらくそれ以前から) よく使用されてきたアプローチはINCLUDE、1 つのソース ファイルのテキストを別のソース ファイルに含める行を使用することです。INCLUDE を回避するための適切なソフトウェア エンジニアリングの理由がたくさんあり、INCLUDE を使用することには多くの実用的な利点があります。

INCLUDE に頼るよりも、Chris が既に概説しているアプローチの方が良いと付け加えておきますが、必要な場合もあります...

于 2012-05-31T14:01:03.090 に答える