'#include'file2.c''与'gcc file1.c file2.c'有什么不同？

Question

如果你不打算重新编译包含的文件，是否有任何理由更喜欢使用包含指令的链接器命令如果？

P.S.如果它很重要，我实际上关心的是C++和g ++，但我认为gcc作为一个通用编译器会更容易识别。

Answer 1

是否有任何理由，更喜欢命令连接在包括指令

是。如果在这里和那里包含实现（.c）文件，则会遇到严重问题。满足连接错误臭名昭著的“符号_Myfunc的多重定义” ...

（顺便说一下，它也被认为是不好的风格/做法，一般来说，只有头文件是为了被包括在内。）

Answer 2

如果你真的只想要一个长的C文件，用你的编辑器将file2.c插入到file1.c中，然后删除file2.c。如果他们总是走在一起，那么（可能）是正确的解决方案。使用#include这不是正确的解决方案。

我们将文件拆分为单独的.c和.cpp文件的原因在于，它们在逻辑上独立于代码的其余部分。当程序很大时，分别编译每个单元是一个好主意，但将事物分解成单独文件的主要原因是显示每个单元代码的独立性。通过这种方式，您可以查看其他部分对此特定文件的影响（查看包含的标题）。如果一个类对于.cpp文件是本地的，那么您知道该类不会被用在系统中的其他地方，所以您可以安全地更改该类的内部，而不必担心其他组件会受到影响。另一方面，如果一切都在一个大文件中，那么很难跟踪影响什么的因素，什么是可以改变的。

Answer 3

以下是区别。 file1.c：

#include <stdio.h> 
static int foo = 37; 
int main() { printf("%d\n", foo); } 

file2.c：

static int foo = 42; 

这两个平凡的模块编译罚款与gcc file1.c file2.c，即使再从未使用过的foofile2.c的定义。 static标识符仅在翻译单元（C的更通常称为模块的版本）内可见。

当你#include "file2.c"在file1.c，您可以有效地插入到file2.cfile1.c，引起标识符冲突前的两个文件现在已经成为一个翻译单元。

通常，从来没有#include C或C++源文件。只有#include标题。