Question

是否有理由更喜欢链接器命令而不是include指令如果你不打算单独重新编译包含的文件？

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

Answer 1

是否有任何理由更喜欢包含指令的链接器命令

是。如果你在这里和那里包含实现（.c）文件，你会遇到严重的麻烦。遇到臭名昭着的“符号_MyFunc的多个定义”链接器错误......

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

Answer 2

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

我们将文件拆分为单独的.c anc .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编译良好，即使file2.c的{{1}}的定义从未使用过。 foo标识符仅在翻译单元中可见（C的版本通常称为模块）。

当您static #include "file2.c"时，您有效地将file1.c插入file2.c，导致在两个文件现在成为一个翻译单元之前发生标识符冲突。

通常，永远不要file1.c C或C ++源文件。只有#include标题。

'#include“file2.c”'与'gcc file1.c file2.c'不同吗？

3 个答案: