图书馆不是只有标题的原因是什么？

我真的很喜欢使用仅头文件的库，因为它们非常易于使用（无需链接器问题或需要单独编译库）。例如，大多数Boost库仅用于标题。但是，然后又有一些部分，比如boost :: python，它需要在之前构建。这是设计选择还是技术需要？图书馆不是只有标题的原因是什么？

我以Boost为例，但如果可能的话，我会赞赏更普遍的答案。

来源

2016-01-20 NOhs

减少编译时间，因为您可以链接到预编译库。对于仅包含头文件的库，您必须每次都使用代码编译库，这会大大增加编译时间。 – Banan

是的，每次使用boost时，编译时间都会增加很多。每次在其中包含实现的模板时，在每个c/cpp文件中，编译器都会重新解释实现。当您从源代码编译Google-Chrome时，首次需要大约24小时的编译，请想象仅在标题中使用模板。 –

当实现所需的头文件时，在全局名称空间中引入了许多丑陋的宏和名称，最简单的隔离方法是仅将其包含在单独的翻译单元中。这就是所谓的**编译器防火墙**，又名“柴郡猫”（我不知道为什么）。另一种方法是重新声明东西，例如一个Windows API函数，但总的来说可以是非常多的工作，并且可以引入一个不错的版本依赖性。 –

使用编译库的最初原因是为了节省编译时间。图书馆可能很大。他们可以是巨大的。

另一个说法是他们保持源代码分开。还有很多不是开源的宇宙。

来源

2016-01-20 11:22:54

赞成只有标题的：

更少的时间来建立/进口
没有连接的麻烦

只针对标题：标题无法解决的与之间

碰撞它们之间的编译时防火墙
没有依赖隐藏可能
增加每个目标的编译时间，包括其标头
添加到从目标导出的符号堆。您的简单测试文件现在可能会导出几千个符号。
（在极端情况下）可能会减少COMDAT可折叠符号之间的分隔，导致符号的多个副本无法从目标输出文件中移除，从而导致膨胀。这应该只发生在ELF上的32k +符号上，但是在其他目标（比如Mach-O）上发生的时间要早得多。

来源

2016-01-20 11:59:17 dascandy

除信息隐藏外，所有问题都是由于原始工具造成的。但是信息隐藏/编译器防火墙是一个真正的问题。因此，我们等待，然后等待，等待，等待模块，例如Daveed的。 –

图书馆不是只有标题的原因是什么？

回答

相关问题