プリコンパイル済みヘッダーを使用するコードがあります。(以前は他の方がやってました)
その中に、いくつかの .h ファイルが含まれています。
現在、既存のプリコンパイル済みヘッダーに含まれていない一般的な .h ファイルを使用するクラスがある場合、それらを投げ込むことで実際にメリットがありますか? たぶんコンパイル速度ですが、クラス/ヘッダーも少しきれいになると思っていましたか?
プリコンパイル済みヘッダーですべきこととすべきでないことは何ですか?
プリコンパイル済みヘッダーを使用するコードがあります。(以前は他の方がやってました)
その中に、いくつかの .h ファイルが含まれています。
現在、既存のプリコンパイル済みヘッダーに含まれていない一般的な .h ファイルを使用するクラスがある場合、それらを投げ込むことで実際にメリットがありますか? たぶんコンパイル速度ですが、クラス/ヘッダーも少しきれいになると思っていましたか?
プリコンパイル済みヘッダーですべきこととすべきでないことは何ですか?
他のソースファイルからそれらのヘッダーを削除することにより、「コードクリーンアップ」のためにプリコンパイル済みヘッダーに含まれているヘッダーに依存しないでください。PCHの使用をやめたい場合、これは悪夢を生み出します。すべてのソースファイルで依存関係を明示的にする必要があります。両方の場所にそれらを含めるだけです-害はありません(適切なインクルードガードが配置されていると仮定します)。
複数のソースファイルにインクルードされているヘッダーファイルは、PCHにインクルードするのに適しています(特に長い場合)。私は、PCHにめったに変更されないヘッダーのみを配置するために、アドバイスをあまり真剣に受け止めていないことがわかりました。ただし、これはプロジェクト全体の構造によって異なります。フルビルドを頻繁に行う場合は、このアドバイスを絶対に避けてください。インクリメンタル再構築の作業を最小限に抑えたい場合は、それを検討してください。私の経験では、PCHの再構築は比較的高速であり、これのコストは、一般的なコンパイルの全体的な高速化(ほとんどの場合)によってはるかに上回っています。すべてのPCHシステムが、PCHに含まれるヘッダーが変更されたときにすべてのソースファイルを再構築する必要がないことを理解できるほど賢いかどうかはわかりませんが(VC ++はそうです)、明示的に#include
すべての翻訳ユニットで必要なものをすべて使用することで、これが確実に容易になります(PCHに含まれているものに依存してはならないもう1つの理由)
コンパイラがコンパイル中に各ファイルのツリーを表示するオプションをサポートしている場合#include
、これはPCHに含める必要のあるヘッダー(最も表示されるヘッダー)を特定するのに非常に役立ちます。私は最近、自分が取り組んでいるプロジェクト(すでにPCHを使用していましたが、最適ではありません)でこれを実行し、C++の75万行のビルドを約1.5時間から15分に高速化しました。
変更されないシステム インクルードをプリコンパイル済みヘッダーに挿入します。これにより、コンパイルが高速化されます。変更する可能性のある独自のヘッダー ファイルをプリコンパイル済みヘッダーに配置しないでください。変更するたびに、プリコンパイル済みヘッダー全体を再構築する必要があります。
これはトレードオフです。システム/ライブラリのヘッダーは、プロジェクトのヘッダーに依存するため、PCH に確実に配置されます。
私たちのプロジェクトには、プロジェクトの他の部分よりも頻繁に変更される大量のコードが生成されています。これらのヘッダーは、個々のファイルでの処理に時間がかかるため、PCH に入れられます。それらを変更すると費用がかかりますが、そのコストと、ファイルにそれらを保持することによるより頻繁な小さな節約とを比較検討する必要があります。