C / C ++インクルードヘッダーファイルの順序

どのような順序でファイルを指定する必要がありますか。つまり、あるヘッダーを別のヘッダーの前に含める理由は何ですか。

たとえば、システムファイル、STL、およびBoostはローカルインクルードファイルの前または後にありますか？

コンパイルされる限り、推奨される順序はないと思います！厄介なのは、一部のヘッダーで最初に他のヘッダーを含める必要がある場合です...これは、インクルードの順序ではなく、ヘッダー自体の問題です。

私の個人的な好みは、各サブセクションをアルファベット順にローカルからグローバルに移動することです。

1. このcppファイルに対応するhファイル（該当する場合）
2. 同じコンポーネントのヘッダー
3. 他のコンポーネントのヘッダー
4. システムヘッダー。

1.の私の理論的根拠は、各ヘッダー（cppがある）が#include前提条件なしで終了できることを証明する必要があるということです（末端技術：ヘッダーは「自己完結型」）。そして、残りはそこから論理的に流れるようです。

心に留めておくべき重要なことは、ヘッダーが最初に含まれている他のヘッダーに依存するべきではないということです。これを保証する1つの方法は、他のヘッダーの前にヘッダーを含めることです。

「Thinking in C ++」では、Lakosの「Large Scale C ++ Software Design」を参照して、これについて特に言及しています。

外部から提供された宣言や定義なしで、コンポーネントの.hファイル自体が確実に解析されるようにすることで、潜在的な使用エラーを回避できます... .cファイルの最初の行に.hファイルを含めることで、重要な部分がないコンポーネントの物理インターフェイスに固有の情報の一部が.hファイルにありません（または、ある場合は、.cファイルをコンパイルしようとするとすぐにわかります）。

つまり、次の順序で含めます。

1. この実装のプロトタイプ/インターフェースヘッダー（つまり、この.cpp / .ccファイルに対応する.h / .hhファイル）。
2. 必要に応じて、同じプロジェクトの他のヘッダー。
3. 他の非標準、非システムライブラリ（たとえば、Qt、Eigenなど）のヘッダー。
4. 他の「ほぼ標準」のライブラリ（Boostなど）のヘッダー
5. 標準のC ++ヘッダー（たとえば、iostream、functionなど）
6. 標準のCヘッダー（cstdint、dirent.hなど）

この順序に含まれることに問題があるヘッダーがある場合は、それらを修正するか（使用している場合）、使用しないでください。きれいなヘッダーを書かないボイコットライブラリ。

GoogleのC ++スタイルガイドはほぼ逆のことを主張しており、まったく正当化されていません。私は個人的にラコスのアプローチを好む傾向があります。

私は、大多数の問題を回避する2つの単純なルールに従います。

1. すべてのヘッダー（そして実際に任意のソースファイル）は、彼らが必要とするものを含むべきです。彼らは物事を含め、ユーザーに依存すべきではありません。
2. 付属物として、すべてのヘッダーにはガードが含まれている必要があります。これにより、上記のルール1の野心的な適用によってヘッダーが複数回含まれることがなくなります。

私は以下のガイドラインにも従います：

1. 最初にシステムヘッダー（stdio.hなど）を分割線に含めます。
2. それらを論理的にグループ化します。

言い換えると：

#include <stdio.h>
#include <string.h>

#include "btree.h"
#include "collect_hash.h"
#include "collect_arraylist.h"
#include "globals.h"

ガイドラインですが、それは主観的なことです。一方、私は厳格に施行し、不快なサードパーティの開発者が私のビジョンにサブスクライブしない場合は、インクルードガードとグループ化されたインクルードを使用して「ラッパー」ヘッダーファイルを提供するところまで行っています:-)

自分のレンガを壁に追加します。

1. 各ヘッダーは自己完結型である必要があり、少なくとも1回は最初に含まれている場合にのみテストできます
2. シンボル（マクロ、型など）を導入して、サードパーティのヘッダーの意味を誤って変更してはなりません。

だから私は通常このように行きます：

// myproject/src/example.cpp
#include "myproject/example.h"

#include <algorithm>
#include <set>
#include <vector>

#include <3rdparty/foo.h>
#include <3rdparty/bar.h>

#include "myproject/another.h"
#include "myproject/specific/bla.h"

#include "detail/impl.h"

次のグループから空白行で区切られた各グループ：

• 最初にこのcppファイルに対応するヘッダー（健全性チェック）
• システムヘッダー
• 依存関係の順序で整理されたサードパーティのヘッダー
• プロジェクトヘッダー
• プロジェクトのプライベートヘッダー

また、システムヘッダーとは別に、各ファイルは名前空間の名前が付いたフォルダーにあります。これは、この方法で追跡しやすいためです。

私はお勧め：

1. 作成している.ccモジュールのヘッダー。（プロジェクト内の各ヘッダーがプロジェクト内の他のヘッダーに暗黙的に依存しないようにするのに役立ちます。）
2. Cシステムファイル。
3. C ++システムファイル。
4. プラットフォーム/ OS /その他のヘッダーファイル（例：win32、gtk、openGL）。
5. プロジェクトの他のヘッダーファイル。

そしてもちろん、可能な場合、各セクション内のアルファベット順。

#includeヘッダーファイルで不要なを回避するために、常に前方宣言を使用してください。

これは正気の世界のどこでも推奨される方法ではないと確信していますが、同じシステム内で字句的にソートされたファイル名の長さでシステムインクルードを並べるのが好きです。そのようです：

#include <set>
#include <vector>
#include <algorithm>
#include <functional>

include-order依存関係の恥を避けるために、他の人々の前に独自のヘッダーを含めることは良い考えだと思います。

これは主観的ではありません。ヘッダーが#include特定の順序であることに依存していないことを確認してください。STLまたはBoostヘッダーを含める順序は問題ではないことを確認できます。

最初に、.cpp ...に対応するヘッダーを含めます。つまり、他のものsource1.cppを含めるsource1.h前に含める必要があります。私が考えることができる唯一の例外は、プリコンパイル済みヘッダーでMSVCを使用する場合stdafx.hです。その場合、何よりも先に含める必要があります。

理由：source1.h他のファイルの前にbefore を含めることで、依存関係なしにスタンドアロンで動作できるようになります。source1.h後日、依存関係が発生した場合、コンパイラは、必要な転送宣言をに追加するよう直ちに警告しますsource1.h。これにより、依存関係者がヘッダーを任意の順序で含めることができます。

例：

source1.h

class Class1 {
    Class2 c2;    // a dependency which has not been forward declared
};

source1.cpp

#include "source1.h"    // now compiler will alert you saying that Class2 is undefined
                    // so you can forward declare Class2 within source1.h
...

MSVCユーザー：プリコンパイル済みヘッダーの使用を強くお勧めします。したがって、#include標準ヘッダー（および変更されない他のヘッダー）のすべてのディレクティブをに移動しstdafx.hます。

.cppに対応する.hppが存在する場合は、対応する.hppから始めて、最も具体的なものから最も具体的でないものまで含めます。このようにして、自己完結していないヘッダーファイル内の非表示の依存関係が明らかになります。

これは、事前にコンパイルされたヘッダーを使用することで複雑になります。これを回避する1つの方法は、プロジェクトをコンパイラ固有にせずに、プロジェクトヘッダーの1つをプリコンパイル済みヘッダーインクルードファイルとして使用することです。

これは、C / C ++の世界では難しい問題であり、標準を超える要素がたくさんあります。

ヘッダーファイルの順序は、squelartが言ったように、コンパイルされる限り、深刻な問題ではないと思います。

私の考えは次のとおりです。これらのすべてのヘッダーに記号の競合がない場合、どの順序でも問題ありません。ヘッダーの依存関係の問題は、欠陥のある.hに#include行を追加することで後で修正できます。

実際の面倒は、一部のヘッダーが（#if条件をチェックすることによって）その上にあるヘッダーに従ってアクションを変更するときに発生します。

たとえば、VS2005のstddef.hには、次のものが含まれます。

#ifdef  _WIN64
#define offsetof(s,m)   (size_t)( (ptrdiff_t)&(((s *)0)->m) )
#else
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

ここで問題：カスタムヘッダー（ "custom.h"）がありoffsetof、システムヘッダーで提供されていない古いコンパイラーを含め、多くのコンパイラーで使用する必要がある場合は、ヘッダーに書き込む必要があります。

#ifndef offsetof
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

そして、必ずすべてのシステムヘッダーの#include "custom.h" 後にユーザーに伝えるようにしてください。そうしないと、offsetofstddef.h の行がマクロ再定義エラーをアサートします。

今後は、このようなケースに遭遇しないようお祈り申し上げます。