C/C++ プロジェクトでは、ヘッダー ファイルを などのディレクトリに配置しinclude
、実装を などの別のディレクトリに配置することが一般的であることを知っていますsrc
。私はさまざまなプロジェクト構造をいじっていますが、これには客観的な理由があるのか 、それとも単に慣例なのか疑問に思っています.
5 に答える
慣習が理由の1つです。ほとんどの場合、効果的な抽象化では、インターフェイスだけを気にし、ヘッダーを見るだけで簡単にできるようにしたいのです。
しかし、それだけが理由ではありません。プロジェクトがモジュールで編成されている場合は、ほとんどの場合、さまざまなモジュールにいくつかのヘッダーを含める必要があり、インクルードディレクトリで他の「ノイズ」ファイルを削除する必要があります。
また、モジュールの再配布を計画している場合は、実装の詳細を非表示にすることをお勧めします。したがって、ヘッダーとバイナリのみを提供します。他に何も含まれていない単一のフォルダーからヘッダーを配布する方が簡単です。
私が実際に好む代替手段もあります-パブリックヘッダーは別のフォルダーに入れられ(これらには最小限のインターフェイスが含まれています-実装の詳細はまったく表示されません)、プライベートヘッダーと実装ファイルは別々です(おそらく、必ずしもそうではありませんが、別々のフォルダーにあります) 。
それはあなたのフォルダ構造をよりきれいに保ちます。ヘッダーとソースファイルは明らかに異なり、さまざまな目的で使用されるため、それらを分離することは理にかなっています。この観点から、質問は基本的に「ソースファイルとドキュメントが異なるフォルダにあるのはなぜですか」と同じです。コンピューターは、フォルダーに何を入れるか、何を入れないかについては非常に不可知論的です。フォルダーは、人間が情報を解析、保存、および呼び出す方法のために、ほとんどの場合、便利な抽象化にすぎません。
ヘッダーファイルは、ビルドした後も引き続き役立つという事実もあります。つまり、ライブラリをビルドしていて、誰かがそのライブラリを使用したい場合は、ソースファイルではなくヘッダーファイルが必要になるため、それらのヘッダーファイルをバンドルする-ものをつかみ、bin
ふるいinclude
にかける必要がないsrc
-はるかに簡単です。
(議論の余地がありますか?) 物事を整頓しておくための有用性、他のプロジェクトでの有用性などに加えて、非常に中立的で客観的な利点が 1 つあります: コンパイル時間です。
特に、多数のファイルを含む大きなプロジェクトでは、ヘッダーの検索パス (.c/.cpp ファイル#include "headername.h"
ではなくを使用#include "../../gfx/misc/something/headername.h"
し、コンパイラーがそれを飲み込めるように適切なパラメーターを渡した) に応じて、数を大幅に減らします。正しいヘッダーを検索するためにコンパイラーがスキャンする必要があるエントリーの数。ほとんどのコンパイラは、コンパイルされたファイルごとに個別に起動するため、インクルード パス上のファイルのリストを読み取り、コンパイルされた各ファイルの正しいヘッダーを探す必要があります。インクルード パスに多数の .c、.o、およびその他の無関係なファイルがある場合、それらの中からインクルードを見つけるのに比例して時間がかかります。
要するに、いくつかの理由:
- 保守可能なコード。
- コードは適切に設計され、きちんとしています。
- コンパイル時間の高速化 (マイナーな変更が行われる場合があります)。
- ドキュメンテーションなどのためのインターフェースのより簡単な分離。
- コンパイル時の循環依存を回避できます。
- レビューしやすい。
それをよく説明している記事Organizing Code Files in C and C++を見てください。