1

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

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

4

3 回答 3

3

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

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

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

于 2012-12-29T07:49:17.160 回答
0

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

我们将文件拆分为单独的 .c 和 .cpp 文件的原因是它们在逻辑上与其余代码分开做一些事情。当程序很大时，单独编译每个单元是一个好主意，但将事物拆分为单独文件的主要原因是为了显示每个代码单元的独立性。这样，您可以查看影响此特定文件的其他部分（查看包含的标题）。如果类是 .cpp 文件的本地类，则您知道该类未在系统中的其他地方使用，因此您可以安全地更改该类的内部结构，而不必担心其他组件会受到影响，例如。另一方面，如果所有内容都在一个大文件中，那么很难了解影响了什么以及可以安全更改的内容。

于 2012-12-29T12:45:41.993 回答
0

这就是区别。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' 的定义foo从未使用过。static标识符仅在翻译单元（C 的版本，通常称为模块）中可见。

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

通常，绝不#include是 C 或 C++ 源文件。只有#include标题。

于 2012-12-29T13:00:05.360 回答