複数の .cpp ファイル (それぞれにメンバー関数の実装が含まれる) を持つクラスを作成し、.h ファイルにクラスの宣言があるとします。また、各 .cpp ファイルには、include ディレクティブを介して .h ファイルが含まれます。
いずれかのメンバー関数 (.cpp ファイル) の実装を変更すると、プログラムを実行するためにすべての .cpp ファイルを再コンパイルする必要があると言われました。つまり、5 つのメンバー関数 (それぞれが .cpp ファイルに実装されている) があり、そのうちの 1 つの .cpp ファイルの実装を変更した場合、変更した 1 つの .cpp ファイルと他の 4 つの .cpp ファイルをコンパイルする必要があります。プログラムを正しく実行するために変更しませんでした。
私の質問は、前のステートメントが正しい場合、なぜそのステートメントが正しいのですか? この概念に関する洞察は役に立ちます。
それは間違っています。特定の実装ファイルに変更がなく、それに含まれるヘッダー ファイルに変更がなく、環境またはコンパイラ オプションに変更がない場合は、再コンパイルする必要はまったくありません。そのファイルのコンパイルに影響するものはすべて変更されていません。
実際、他のファイルがまったくなくても、各ファイルをコンパイルできます。次に、すべての実装ファイルを同じ場所に置くことなく、すべてのコンパイル済みファイルをリンクできます。
声明は誤りです。実際、すべての理由make(および同様の理由) が存在するのは、それが間違っているためです。どのソース ファイルが変更されたかを追跡し、ソース ファイルに依存するオブジェクト ファイルのみを再作成することで、アプリケーションを再構築する時間/労力を最小限に抑えます。変更されたこと。最新のオブジェクト ファイルはそのままにしておきます。
すべてのオブジェクト ファイルが最新の状態になると、それらがリンクされて最終的な実行可能ファイルが生成されます (これは通常、少なくとも 1 つのオブジェクト ファイルが現在の実行可能ファイルよりも新しい場合にのみ行われます)。
もちろん、makeコンパイルやリンクに関係のない仕事にも使用できますが、それが最も一般的な用途であり、(少なくともほとんどの) それらが発明された理由です (唯一の明白な変更は元々は C++ ではなく C ソース コードに主に使用されていましたが、この点では 2 つをほとんど区別できません)。
この 2 つの唯一の明らかな違いは、テンプレートを使用する場合は、通常、多くのコードをヘッダーに配置することになります。この場合、ヘッダーを変更すると、そのヘッダーを含むすべてのコードが強制的に再コンパイルされますが、これは多くの場合、大量になります。C コードおよび/または非テンプレート C++ コードでは、ほとんどのコードをソース ファイルに入れるため、コードへのインターフェイスを変更した場合 (通常はヘッダーが変更される)、他のファイルを再コンパイルするだけで済みます。ただし、インターフェイスを変更せずに変更を実装に制限する場合は、そのファイルのみを再コンパイルする必要があります。
他の人が言ったように、その声明は誤りです。ただし、変更されたソース ファイル、ソースの依存関係、および再コンパイルに関して興味深い複雑な問題が存在します。これに関する最も有益な議論は、当然のことながら、Herb Sutter による一連の Guru of the Week の投稿で与えられており、依存関係の分離と Pimpl のイディオムについて議論しています。
このようなものは、ほとんどの人が初めて見たときは難解に見えますが、Pimpl のイディオムは実際には驚くほど便利であることが判明しました。