私は、可能な場合は前方宣言を使用し、もう 1 つは前方宣言を使用しないという点を除いて同じ 2 つの C++ プロジェクト間のコンパイル時間の比較を示す研究や経験的データに非常に興味があります。
完全なインクルードと比較して、前方宣言によってコンパイル時間はどの程度劇的に変化するのでしょうか?
#include "myClass.h"
対
class myClass;
これについて調査した研究はありますか?
これはプロジェクトに大きく依存する漠然とした質問であることは承知しています。明確な数字での回答は期待していません。むしろ、誰かがこのことに関する研究を教えてくれることを望みます。
私が特に心配しているプロジェクトには、約 1200 個のファイルがあります。各 cpp には平均 5 個のヘッダーが含まれています。各ヘッダーには平均 5 個のヘッダーが含まれています。これは約 4 レベルの深さで後退します。コンパイルされた各 cpp ごとに、約 300 個のヘッダーを開いて解析する必要があり、その一部は何度も解析されるようです (インクルード ツリーには重複が多数あります)。ガードはありますが、ファイルは開かれたままです。各 cpp は gcc で個別にコンパイルされるため、ヘッダー キャッシュはありません。
誤解のないように言っておきますが、私は可能な限り前方宣言を使用することを強く推奨します。しかし、私の雇用主はそれを禁止しています。私はその立場に反論しようとしています。
情報があればよろしくお願いします。
ベストアンサー1
前方宣言により、よりわかりやすく整ったコードを作成できるようになります。これは、あらゆる決定の目標となるはずです。
これに加えて、クラスに関しては 2 つのクラスが互いに依存する可能性が非常に高いため、悪夢を引き起こさずに前方宣言を使用しないことは少し困難になります。
同様に、ヘッダー内でクラスを前方宣言するということは、実際にそれらのクラスを使用する CPP に関連ヘッダーのみを含める必要があることを意味します。これにより、実際にコンパイル時間が短縮されます。
編集: 上記のコメントを踏まえて、ヘッダー ファイルをインクルードする方が前方宣言するよりも常に遅くなることを指摘しておきます。ヘッダーをインクルードするたびに、ディスクからのロードが必要になりますが、ヘッダー ガードによって何も起こらないことが判明することがよくあります。これは膨大な時間を無駄にすることになり、導入するには非常に愚かなルールです。
編集2: 確かなデータを入手するのはかなり困難です。逸話として、私はかつて、ヘッダーのインクルードに関して厳密ではないプロジェクトに携わったことがあり、512MB RAM P3-500Mhz でビルド時間が約 45 分でした (これはかなり前のことです)。2 週間かけてインクルードの悪夢を削減した後 (前方宣言を使用して)、コードを 4 分弱でビルドできるようになりました。その後、可能な限り前方宣言を使用するのがルールになりました。
編集3: また、コードに小さな変更を加える場合、前方宣言を使用することで大きな利点があることも覚えておく価値があります。ヘッダーがショップ全体に含まれている場合、ヘッダー ファイルを変更すると、膨大な量のファイルが再構築される可能性があります。
また、プリコンパイル ヘッダー (PCH) の長所を称賛する人もたくさんいます。PCH には独自の用途があり、非常に役立ちますが、適切な前方宣言の代わりに使用すべきではありません。そうしないと、ヘッダー ファイルの変更によって、多数のファイルの再コンパイルで問題が発生する可能性があり (前述のとおり)、PCH の再構築も発生します。PCH は、プリビルドされたライブラリなどでは大きなメリットをもたらしますが、適切な前方宣言を使用しない理由にはなりません。