链接与包含文件答案

【问题标题】：linking vs including a file链接与包含文件
【发布时间】：2012-02-29 17:52:37
【问题描述】：

在使用大型代码库时，我看到在使用某个对象时，会包含该对象的头文件。在其他时候，该对象的库链接在 make 文件中。

做其中一个的原因是什么。如果他们可以访问源代码，为什么不包含您正在使用其对象的所有文件，而不是链接到他们的 lib *.a 文件？

编辑：根据第一条评论说清楚。这是一个令人困惑的声明

【问题讨论】：

“头文件链接在makefile中”是什么意思？
目标文件已链接。不是头文件AFAIK。
解决了我的问题。我跳过了非常重要的描述。
我将这个问题解读为：“有些人将 C++ 文件编译为共享对象或 DLL，然后将其链接到他们的代码中，而有些人则使用相同的文件（例如 file.cpp）并执行不编译它，而是在他们的代码中#include“file.cpp”......那么这两种不同的方法访问和使用file.cpp中的代码的原因是什么？”你问的是这个吗？
是的。这就是我的意思，但不是“某些人”。我看到这发生在同一个代码库中。

标签： c++ linker

【解决方案1】：

通常，您需要同时执行这两项操作。头文件告诉编译器什么功能可用，以及它们的外观。他们必须是编译时出现。库包含实现，以及必须与应用程序链接才能生成编译器打电话上班。

在极少数情况下，“库”可能仅包含头文件； C++ 仍然需要模板的实现存在于头文件，而不是在库中，所以一个库只包含模板可能只有标题。在这种情况下，足以包括标题；没有什么可以链接的了。（当然，这样的库将编译时间推到了顶峰。）

【讨论】：

【解决方案2】：

头文件和二进制文件之间不一定是一对一的关系。事实上，通常没有。例如，仅仅因为您看到包含 foo.h 并不一定意味着会有 foo.obj 或 foo.lib。反之亦然；即，您可能会看到 foo.lib 被链接但没有 foo.h。

以Windows为例，你需要相当多的头文件才能使用kernel32.lib中的任何东西，但是没有kernel32.h。

【讨论】：

【解决方案3】：

使用库的一个很好的论据是可以更轻松地使用：要编译大型代码库，所有正确依赖项都必须可用，并且可能需要特定步骤，但与手头的任务。当然，它还缩短了编译时间。

【讨论】：