为什么不是所有Boost库都只有标头？

Question

为什么Boost中的所有库都不是标题？换句话说,是什么使得.lib/.dll的使用是强制性的？

当一个类不能成为模板或具有静态字段时？

Answer 1

我猜不同点.

• 二进制大小.标头只能给客户端带来规模负担吗？
• 编译时间.头文件是否意味着编译性能显着下降？
• 运行时性能.标题只能提供卓越的性能吗？
• 限制.设计是否只需要标题？

关于二进制大小.

^{还有一点安全感}

如果boost库中有很多可访问的代码,或者编译器无法争论它是否可由客户端访问的代码,则必须将其放入最终的二进制文件中.^(*)

在具有包管理(例如,基于RPM或.deb)的操作系统上,共享库可能意味着二进制分发大小的大幅减少并具有安全优势:安全修复程序分发更快,然后由所有.so /自动使用. .DLL用户.所以你有一个重新编译和一个重新分配,但N个奸商.使用仅限标头的库,您有N次重新编译,N次重新分配,每次修复都有,并且这些N中的某些成员本身已经很大.

^{(*)此处可达表示"可能已执行"}

关于编译时间.

一些提升库是巨大的.如果你愿意#include,每次你在源文件中改变一点,你必须重新编译你所有的东西#include.

这可以用樱桃挑选的标题来反测量,例如

#include <boost/huge-boost-library.hpp> // < BAD
#include <boost/huge-boost-library/just-a-part-of-it.hpp> // < BETTER

但有时你真正需要包含的东西已经足够大,可以削弱你的重新编译.

对策是使其成为静态或共享库,反过来意味着"完全编译一次(直到下一次提升更新)".

关于运行时性能.

我们还处于一个时代,全局优化解决了我们所有的C++性能问题.为了确保为编译器提供所需的所有信息,您可以只使用头文件并让编译器做出内联决策.

在这方面,请注意,由于CPU上的缓存和推测问题,内联并不总是表现出优异的性能.

还要注意,这个论点主要是关于可能经常使用的boost库,例如,人们可能会boost::shared_ptr<>经常使用,因此是一个相关的性能因素.

但考虑到真正的,唯一相关的原因boost::shared_ptr<>是仅限标题......

关于限制.

C++中的一些东西不能放入库中,即模板和枚举.

但请注意,这只是中途的一半.您可以为实际数据结构和算法编写类型安全的模板化接口,这些接口又在库中具有运行时通用实现.

同样,C++中的一些东西应放入源文件中,如果是boost,则放入库中.基本上,这是一般会产生"多重定义"错误的所有内容,例如static成员变量或全局变量.

一些实例中,也可以在标准库中发现:std::cout在标准中定义为extern ostream cout;,依此cout基本上需要的分布东西定义它(库或的资源文件)一次且仅一次.