事実: ( class-type の)前方宣言は、インクルードよりも優先されます。
ヘッダー内のすべてを前方宣言し、そのヘッダーを含めることにマイナス面はありますか? (コンパイル時間はそれほど増加しないはずだと思います)
大規模なコードベースでは、前方宣言は多くの画面スペースを占める可能性があり、それらを単一のインクルードに置き換えるのはクールですが、ヘッダーごとに前方宣言ヘッダーを使用しても意味がありません。前方宣言。
誰かがこれをやった、またはこれを見たことがありますか?
事実: ( class-type の)前方宣言は、インクルードよりも優先されます。
ヘッダー内のすべてを前方宣言し、そのヘッダーを含めることにマイナス面はありますか? (コンパイル時間はそれほど増加しないはずだと思います)
大規模なコードベースでは、前方宣言は多くの画面スペースを占める可能性があり、それらを単一のインクルードに置き換えるのはクールですが、ヘッダーごとに前方宣言ヘッダーを使用しても意味がありません。前方宣言。
誰かがこれをやった、またはこれを見たことがありますか?
極端に行かなければ、転送インクルードのマイナス面はほとんどないと思います。
私は個人的に画面スペースを気にしません。ビルド時間を 2 倍から 5 倍、10 倍にすることは確かに優れています。ビルド時間は約 2 時間以上かかりました....いくつかの余分な前方インクルードにより、同じファイルが何千回もヒットするのを防ぐことができました。
とにかく、常にすべてに対して前方宣言を使用できるとは限りません。何かをサブクラス化する場合は、クラス定義が必要であり、それはインクルードを意味する可能性があります。それはいいです。
依存関係を削除するためにできることの 1 つは、ヘッダー ファイルでコードをインライン展開することです。必ずインターフェイスを押し上げ、実装を押し下げてください (Sutter と Alexandrescu による C++ コーディング標準を参照してください)。つまり、可能であれば、パブリック API を抽象インターフェイスにすることをお勧めします。それができれば、含めるか前方宣言する必要がある金額を最小限に抑えることができます。
また、1 つのヘッダー ファイルに何百もの関数とクラスを配置しないでください。そのため、8000 行の長さになります。誰もそのようなファイルを読んだり理解したりすることはできません。
私は通常、自分のプロジェクトでそうします。しかし、前方宣言を で分割しましたmodules
。例:gui
などcore
。これにより、ヘッダーにインクルードを使用するために何度も再コンパイルすることと、前方宣言を手動で記述することの間でバランスが取れます
インクルードの代わりに前方宣言を使用する主な利点の 1 つは、ヘッダー ファイルが実際に必要な場所にのみインクルードされるため、ヘッダー ファイルを変更するたびに多くのソース ファイルを再コンパイルする必要がないことです。
あなたのアプローチはこの利点を減らし、場合によってはさらに悪化させる可能性があります: どこかでクラスを追加または削除するたびに、前方宣言を含むグローバル ヘッダー ファイルを変更する必要があります。そして、追加されたクラスを使用しないものを含め、コードベース内のすべてのソース ファイルを再コンパイルする必要があります。
それでも、クラスはおそらくあまり頻繁に追加されないため、これはそれほど悪いトレードオフではありません。