この章では、Scott Meyerが、ヘッダーファイルの依存関係を回避するためのいくつかの手法について説明しました。主な目標は、変更が他のインクルードされたヘッダーファイルに限定されている場合に、cppファイルの再コンパイルを回避することです。
私の質問は次のとおりです。
私の過去のプロジェクトでは、このルールに注意を払ったことはありませんでした。コンパイル時間は短くはありませんが、耐えられません。それは私のプロジェクトの規模（または欠如）ともっと関係があるかもしれません。コンパイラ技術（clangなど）の進歩を考えると、このヒントは今日どれほど実用的ですか？
このテクニックの使用例はどこにありますか？（例：Gnomeまたはその他のOSSプロジェクト）
PS私は第2版を使用しています。
コンパイル時間を短縮することは、厄介な問題であり、時期尚早の最適化の一形態です。コンパイル時間を短縮するためにコードを再編成することは（これが重要な場合）行うことができますが、どういうわけか大きなコストがかかります。
Gnomeに関しては、GnomeはすべてのGObjectに「プライベートポインタ」を持っています。これは、pimplイディオムを実装します。これにより、ソースファイル間の依存関係が減少し、何らかの形式のカプセル化が可能になります。Cプロジェクトのコンパイル時の問題は少なくなります。
最新のC++設計ではテンプレートを多用しているため、必然的にコンパイル時間が急増します。pimplイディオムとフォワード宣言クラスを使用すると（可能な場合はヘッダーを含める代わりに）、変換ユニット間の論理的な依存関係が減少します（これは良いことです）が、多くの場合、コンパイル時間にはあまり役立ちません。
使用boostするとコンパイル時間が大幅に増加し（多くのソースファイルに間接的にブーストヘッダーを含める場合は注意してください）、多くのC++プロジェクトで使用されます。
薄いテンプレートのイディオムは、テンプレートによるコードの膨張を減らすためによく使用されます。
コンパイラ技術は特に進歩していないと思います。clangは魔法のようなものではありません。依存関係があり、変更を加えた場合、依存関係のあるコードを再コンパイルする必要があります。これには非常に長い時間がかかる可能性があります。大きなプロジェクトの場合は読み取り時間、さらには数日かかるため、人々は可能な限りそのような依存関係を最小限に抑えようとします。
そうは言っても、すべてのクラスをPIMPLにしたり、すべてを前方に宣言したりするなど、やりすぎる可能性があります。これを行うと、コードが難読化されるため、可能な限り避ける必要があります。