A.cc、B.cc、C.cc、およびそれらに関連付けられたヘッダー ファイルなど、多数の C++ ファイルがあるとします。A.cc は B.cc などのクラスを利用します。
ここで、ソース ファイルをビルドするとします。前処理フェーズの後、理論上、すべてのファイルを同時にコンパイル (リンクではなく) できますか? (A.cc -> A.obj, ...)
B.cc をコンパイルする前に、A.cc のコンパイルが完了するまで待たなければならない場合があるのではないかと思っています。
A.cc、B.cc、C.cc、およびそれらに関連付けられたヘッダー ファイルなど、多数の C++ ファイルがあるとします。A.cc は B.cc などのクラスを利用します。
ここで、ソース ファイルをビルドするとします。前処理フェーズの後、理論上、すべてのファイルを同時にコンパイル (リンクではなく) できますか? (A.cc -> A.obj, ...)
B.cc をコンパイルする前に、A.cc のコンパイルが完了するまで待たなければならない場合があるのではないかと思っています。
いいえ、実際に奇妙なことをしていない限り、のコンパイルはコンパイルの結果に依存しB.cc
ませんA.cc
(逆も同様です)。そのため、make -j
(複数の「ジョブ」、つまりプロセスを並行して実行し、それぞれが同時にファイルをコンパイルする)は、特にもちろんマルチコアマシンで人気のある使用法です(ただし、複数のコアがなくても少数の同時ジョブは、任意にシリアル化された同じ一連のジョブよりも最終的に速く終了する可能性があります.1つはディスクI / Oを待ってブロックされる可能性があり、もう1つはコンパイルのCPU集約的な部分をかき回しています...). . 利用可能な物理 RAM が十分にある限り、つまり;-)。
実際にそのような依存関係が必要な場合は1つだけです。つまり、1つのファイルが後でコンパイルされるC++コードを生成する場合です。Makeはこれをサポートするのに十分な柔軟性があります。しかし、通常のプロジェクトについて考えるとき、いいえ、そのような依存関係は必要ありません。
それがヘッダーの目的ですよね?make -j N がこれを行いますが、ユーザーが生成した間違いやすい Makefile に基づいて行います。
ファイルの末尾の拡張子は、多かれ少なかれ無意味です。重要なのは、まだ実装されていなくても、コンパイルしようとしているすべてのクラスの完全な定義を持っているということです。.h および .cc または .cpp 拡張子は任意であるため、最も重要なのはファイルの内容です。
一般的に言えば、クラスのオブジェクトを完全に記述することができれば、問題に遭遇することはありません。設定したチェーンにクラス定義がまだ存在しない場合 (これは、循環依存ヘッダーで発生する可能性があります)、何らかの魔法を行う必要があります。
ポイントは、この問題に遭遇するかどうかは、デザイナー/開発者としてのあなた次第だということです.