インクルードファイルの注文方法

Question

インプリメンテーションファイル（.cc/.cpp）に対応するクラスdefinition file firstが含まれ、他のヘッダーファイルを含める前に、かなり一貫したアドバイスが見られました。しかし、トピックがヘッダーファイル自体に移動し、それらが含んでいる順番が変わると、アドバイスは変化するようです。

が示唆：

1. DIR2/foo2.h（好ましい位置 - 詳細は下記を参照のこと）。
2. システムファイル。
3. C++システムファイル。
4. 他のライブラリの.hファイル。
5. プロジェクトの.hファイル。

上記のエントリ1と5の違いは何か、そしてなぜ1つまたは他の場所が選択されるのかは不明です。

1. システムは
2. プロジェクトは地元
3. がもう一度あり

が含まれて含まれていますそれはanother online guideが（そのドキュメントの「クラスレイアウト」セクションにあります）この順序を示唆している、と述べましたあいまいさ、今回は2と3の間です。違いは何ですか？それらはプロジェクト間およびプロジェクト内のものを表していますか？

しかし、これまでのところ、両方の提案されたコーディング標準では、「あなたの」ヘッダーファイルが最後に含まれているように見えます。そのようなアドバイスは、実装ファイルのインクルード順に推奨されているものから後ろ向きであり、直感的ではありません。 「あなたの」ヘッダーファイルが一貫して最初にリストされていることは理にかなっていませんか？

Answer 1

あなたのインクルードを記載する順番は、技術的な観点からは重要ではありません。あなたがそれを正しく設計したなら、あなたは望む順番にそれらを置くことができなければならず、それでも動作します。たとえば、foo.hに<string>が必要な場合は、foo.hの中に含める必要があります。したがって、fooを使用する場合は、その依存関係を覚えておく必要はありません。

の場合はに順序依存関係がある場合、定義ファイルを最後に置くとほとんどの場合それが修正されます。これはfoo.hが<string>に依存していますが、それ以外の方法ではありません。

あなたは定義ファイルを最後に置くのが良いケースになると思うかもしれませんが、実際には全く反対です。コーディング標準で最初に定義が必要な場合、コンパイラは最初に記述されたときに誤った順序依存関係を検出する可能性が高くなります。 Googleのスタイルについて

Answer 2

私は逐語的な標準は認識していませんが、一般的な経験則として、コンパイル時間、競合、および依存性を減らすために、特に他のヘッダーファイル内に可能な限り小さなヘッダーが含まれています。私はヘッダーファイルのクラスの前方宣言を使用するファンです。ヘッダーと定義を.cppサイドに含めることができれば、私はそうすることができます。ヘッダについては

：

1. C++ヘッダ
2. サードパーティのヘッダ
3. 他のプロジェクトのヘッダ
4. 、このプロジェクトのヘッダ

私の個人的な好みは以下であることを特徴とする

ソース：

1. プリコンパイル済みヘッダーファイル
2. このソースファイルのヘッダ
3. C++ヘッダ
4. サードパーティのヘッダ
5. 他のプロジェクトのヘッダ
6. 、このプロジェクトのヘッダ

ポインタや提案は、通常、競合や循環参照を避けるため、それ以外の場合は個人的な好み、あるいはあなたが共同プロジェクトのために遵守したい方針を選んでください。

Answer 3

：

あいまいは全くありませんが。

最初のヘッダーは、ソースファイルthisに関連するヘッダーである必要があります。このようにして、必要なものがすべて含まれていることと、「隠された」依存関係がないことを確認します。すぐに暴露され、編集が妨げられるでしょう。

他のヘッダーは、あなたの可能性が高い問題に問題が発生した場合に、変更する可能性が最も低い順に並べられています。識別子の衝突、マクロの漏洩などの問題が発生する可能性があります。

CおよびC++システムヘッダーは非常に稀にしか変更されていません。単に使用するユーザーが非常に多いためです。

サードパーティのコードは変更することができますが、一般的に面倒で時間がかかるため、3番目になります。

「プロジェクトインクルード」とは、いくつかのプロジェクトで使用されている一般的な家庭用ライブラリ（ミドルウェア）を指します。彼らは変更することができますが、これは他のプロジェクトにも影響を与えます。

最後に、このプロジェクトに固有のファイルで、誰にも影響を与えずに変更できる「ローカルインクルード」です。問題が発生した場合は、それが最優先候補です。

実際にはもっと多くの層があることに注意してください（特にソフトウェアショップでは）、重要なアイデアは下位層（システムライブラリ）から上層までの依存関係を順序付けることです。

あるレイヤー内で、私はアルファベット順に整理する傾向があります。なぜなら、レイヤーを確認する方が簡単だからです。