インクルード ファイルを個別に再コンパイルする予定がない場合、インクルード ディレクティブよりもリンカー コマンドを優先する理由はありますか?
PS それが問題であれば、私は実際には C++ と g++ に関心がありますが、gcc は一般的なコンパイラとして認識されやすいと思いました。
インクルード ファイルを個別に再コンパイルする予定がない場合、インクルード ディレクティブよりもリンカー コマンドを優先する理由はありますか?
PS それが問題であれば、私は実際には C++ と g++ に関心がありますが、gcc は一般的なコンパイラとして認識されやすいと思いました。
インクルード ディレクティブよりもリンカー コマンドを優先する理由はありますか
はい。.c
あちこちに実装 ( ) ファイルを含めると、深刻な問題が発生します。悪名高い「シンボル _MyFunc の複数の定義」リンカ エラーに遭遇します...
(ちなみに、これは悪いスタイル/慣行とも考えられています。一般に、ヘッダー ファイルのみを含めることを意図しています。)
違いは次のとおりです。file1.c
:
#include <stdio.h>
static int foo = 37;
int main() { printf("%d\n", foo); }
file2.c
:
static int foo = 42;
これらの2つの些細なモジュールは、の定義が使用されないgcc file1.c file2.c
場合でも、で正常にコンパイルされます。識別子は、変換ユニット(より一般的にモジュールと呼ばれるもののCバージョン)内でのみ表示されます。file2.c
foo
static
に入る#include "file2.c"
とfile1.c
、に効果的に挿入file2.c
されfile1.c
、2つのファイルが1つの変換単位になる前に識別子の衝突が発生します。
原則として、#include
CまたはC++のソースファイルは使用しないでください。#include
ヘッダーのみ。
本当に 1 つの長い C ファイルだけが必要な場合は、エディターを使用して file2.c を file1.c に挿入し、次に file2.c を削除します。彼らが常に一緒に行くなら、それは(おそらく)正しい解決策です. これに #include を使用するのは適切な解決策ではありません。
ファイルを個別の .c anc .cpp ファイルに分割する理由は、これらのファイルが論理的に残りのコードとは別のことを行うためです。プログラムが大きい場合、各ユニットを別々にコンパイルすることは良い考えですが、物事を別々のファイルに分割する主な理由は、コードの各ユニットの独立性を示すことです。このようにして、この特定のファイルに影響を与える他の部分を確認できます (含まれているヘッダーを見てください)。クラスが .cpp ファイルに対してローカルである場合、クラスがシステム内の他の場所で使用されていないことがわかっているため、たとえば、他のコンポーネントが影響を受けることを心配することなく、そのクラスの内部を安全に変更できます。一方、すべてが 1 つの大きなファイルに含まれている場合、何が影響を与えているのか、何が安全に変更できるのかを追跡することは非常に困難です。