ある C ソースファイルを別の C ソースファイルに含めるには? 質問する

Question

適切に使用すれば、これは便利なテクニックになります。

かなり小さなパブリックインターフェイスと、再利用できない実装コードが大量にある、複雑でパフォーマンスが重要なサブシステムがあるとします。コードは数千行に及び、プライベート関数は 100 個程度、プライベートデータもかなりあります。重要な組み込みシステムを扱う場合、おそらくこのような状況に頻繁に遭遇するでしょう。

ソリューションはおそらく階層化され、モジュール化され、分離されており、これらの側面はサブシステムのさまざまな部分を異なるファイルにコーディングすることで効果的に表現および強化できます。

C では、これを行うと多くのものを失う可能性があります。ほぼすべてのツールチェーンは、単一のコンパイル単位に対して適切な最適化を提供しますが、extern と宣言されたものについては非常に悲観的です。

すべてを1つのCソースモジュールにまとめると、次のようになります。

パフォーマンスとコードサイズの改善 - 多くの場合、関数呼び出しはインライン化されます。インライン化しない場合でも、コンパイラはより効率的なコードを生成する機会があります。
リンクレベルのデータと関数の非表示。
名前空間の汚染とその結果としての回避 - 扱いにくい名前をあまり使用しなくなります。
コンパイルとリンクが高速化されます。

しかし、このファイルを編集する際には、混乱が生じ、暗黙のモジュール性が失われます。これは、ソースを複数のファイルに分割し、これらを組み込んで単一のコンパイル単位を作成することで克服できます。

ただし、これを適切に管理するには、いくつかの規則を課す必要があります。これらはある程度ツールチェーンに依存しますが、一般的な指針は次のとおりです。

パブリックインターフェイスを別のヘッダーファイルに配置します。いずれにしても、これを実行する必要があります。
すべての補助的な .c ファイルを含む 1 つのメイン .c ファイルを用意します。これには、パブリックインターフェイスのコードも含めることができます。
コンパイラガードを使用して、プライベートヘッダーとソースモジュールが外部コンパイルユニットに含まれないようにします。
すべてのプライベートデータと関数は静的に宣言する必要があります。
.c ファイルと .h ファイルの概念的な区別を維持します。これにより、既存の規則が活用されます。違いは、ヘッダーに多くの静的宣言が含まれることです。
ツールチェーンで特に理由がない場合は、プライベート実装ファイルに .c および .h という名前を付けます。インクルードガードを使用すると、コードは生成されず、新しい名前も追加されません (リンク中に空のセグメントがいくつか発生する可能性があります)。大きな利点は、他のツール (IDE など) がこれらのファイルを適切に処理することです。

Answer 1