Question

为什么要将各种源代码文件编译成各种目标文件然后链接？

在main.c中#include它们会更容易，然后只编译main.c吗？

示例：

具有一个函数foo和main的程序：

void foo(void);

int main() {
        foo();
        return 0;
}

void foo(void)
{
        // do things.
}

通常的方法是将其分成3个文件：

foo.h中

void foo(void);

的main.c

#include "foo.h"

int main() {
        foo();
        return 0;
}

foo.c的

#include "foo.h"

void foo(void) {
        // do things.
}

然后人们会编译它们并链接.o生成的。

问题是：

1.-有没有理由不做以下事情？

2.-如果是这样，何时最好做以下事情，何时不做？

我的方法：

foo.h中

void foo(void);

的main.c

#include "foo.h"

int main() {
        foo();
        return 0;
}

#include "foo.foo"

编辑：foo.foo

void foo(void) {
        // do things.
}

这样我只关心编译main.c

这对我来说更加自然，随着时间的推移＆＃34;复制粘贴＆＃34;进入主要。

我已经知道如果程序是封闭源代码，你想为编译后的文件提供标题，但是因为这个原因我放了开源代码。

Answer 1

（许多）原因之一是编译速度：如果将所有代码放在一个文件中，就像你的方法一样，每次更改内容时都必须重新编译整个项目。

如果项目被拆分为多个文件（对象），则只需重新编译与已更改的文件对应的部分，然后重新执行链接步骤。这通常使用构建系统（经典示例为make）完成，该系统查看所有源文件，所有目标文件，并更新过时的文件。 / p>

编译速度对于小型项目来说不是一个大问题，但对于大型项目来说肯定是，尤其是对于C ++：从头开始构建可能需要数小时甚至数天，因此您希望能够重用尽可能多的目标文件。可能的。

Answer 2

如果许多不同的应用程序使用相同的资源会怎样？

最好将相同的代码静态编译到不同的应用程序中吗？可以在运行时动态共享和链接对象。

Answer 3

1.-有没有理由不做以下事情？

避免#include个.c个文件。开发人员（和软件工具）倾向于将.c文件视为翻译单元。

.c文件创建的目标文件在编译后可以单独保留，除非它发生更改或其中一个依赖项（如头文件）发生更改，从而导致构建速度更快。如果所有内容都#included放入main的文件中，则必须在每次更改每个文件时重建该文件。

编辑：将foo.c重命名为foo.foo后

我也会避免使用一些独特的扩展来调用C传统文件，因为C程序员（和开发工具）也不知道如何处理它们。

2.-如果是这样，何时最好做以下事情，何时不做？

永远不要IMO。可能会接受大static个表格，但我仍然会将它们放在.h文件中。

如果程序与下面的评论中描述的一样简单，我可能会将其保留为一个翻译单元，就像您在第一个代码示例中一样。