为什么不是所有的Boost库仅邮件头？ [英] Why are not all boost libraries header-only?
问题描述
为什么升压所有lib中都没有标题而已？
说不同，是什么让强制使用的.lib / .DLL？
Why all lib in Boost are not headers only ? Saying differently, what makes mandatory the use of .lib/.dll ?
是不是当一个类不能被模板或具有静态字段？
Is it when a class can't be template or has static fields ?
推荐答案
的不同点，我想。
- 二进制文件的大小。头可以只放一个大小负担在客户端上？
- code尺寸。头可以只意味着编译性能显著减少？
- 运行时性能。头能只给性能优越？
- 限制。设计是否Require头只？
和一点安全功能 的
如果有很多可达code在Boost库，或code哪些编译器不能说是否是由客户端访问的，它必须被放入最终的二进制。 （*）
If there's a lot of reachable code in the boost library, or code about which the compiler can't argue whether it is reachable by the client, it has to be put into the final binary. (*)
在有包管理操作系统（例如RPM-或.deb文件为主），共享库可能意味着二进制发行规模大的下降，有安全优势：安全修补程序分发更快，然后自动被所有使用的.so / .DLL用户。所以，你有一个重新编译和一个再分配，但是的 N 的奸商。与只有头库，你的 N 的重新编译，的 N 的再分发，始终为每修复和世界一些成员的 N 的是巨大的自己了。
On operating systems that have package management (e.g. RPM- or .deb-based), shared libraries can mean a big decrease in binary distribution size and have a security advantage: Security fixes are distributed faster and are then automatically used by all .so/.DLL users. So you had one recompile and one redistribution, but N profiteers. With a header-only library, you have N recompiles, N redistributions, always for each fix, and some member of those N are huge in themselves already.
（*）可达这里的意思是潜在的执行
有些Boost库是巨大的。如果您对该的#include 这一切，每次你改变你的源文件中的一点，你必须重新编译你的一切的#include D。
Some boost libraries are huge. If you would #include it all, each time you change a bit in your source-file, you have to recompile everything you #included.
这可以反测樱桃采摘头，例如。
This can be counter-measured with cherry picked headers, e.g.
#include <boost/huge-boost-library.hpp> // < BAD
#include <boost/huge-boost-library/just-a-part-of-it.hpp> // < BETTER
但有时你真的需要包括的东西已经足够大，以削弱你重新编译。
but sometimes the stuff you really need to include is already big enough to cripple your recompiles.
的对策是让静态或共享库，又意为编译完全一次（直到下一个升压更新）。
The countermeasure is to make it a static or shared library, in turn meaning "compile completely exactly once (until the next boost update)".
我们仍然没有在一个时代是全球性的优化解决我们所有的C ++性能问题。为了确保你给出的编译器它需要的所有信息，你可以做的东西仅标头，让编译器内联做出决定。
We are still not in an age were global optimization solves all of our C++ performance problems. To make sure you give the compiler all the information it needs, you can make stuff header-only and let the compiler make inlining decisions.
在这方面，请注意，内联给并不总是因为CPU的缓存和猜测的问题优异的性能。
In that respect, note that inlining gives not always superior performance because of caching and speculation issues on the CPU.
还请注意，这种说法主要是与问候Boost库可能被频繁使用不足，例如人们可以期待的boost :: shared_ptr的＆LT;方式＆gt; 将经常使用的，因而是一个相关的性能因素
Note also that this argument is mostly with regards to boost libraries that might be used frequently enough, e.g. one could expect boost::shared_ptr<> to be used very often, and thus be a relevant performance factor.
但考虑到现实，只有相关的原因的boost :: shared_ptr的＆LT;＆GT; 是仅标头...
But consider the real and only relevant reason boost::shared_ptr<> is header-only ...
在C ++中的一些东西可以的不的投入库，即模板和枚举。
Some stuff in C++ can not be put into libraries, namely templates and enumerations.
但是请注意，这只是一半真的。您可以编写类型安全的，模板化的接口，你的真实数据结构和算法，进而有他们在库的实现。
But note that this is only halfway true. You can write typesafe, templated interfaces to your real data structures and algorithms, which in turn have their implementation in a library.
同样，一些C ++的东西的应的投入的源文件，并在提升，图书馆的情况。基本上，这是，这将使多重定义的错误，如静态成员变量或全局变量一般的一切。
Likewise, some stuff in C++ should be put into source files, and in case of boost, libraries. Basically, this is everything that would give "multiple definition" errors, like static member variables or global variables in general.
一些例子也可以在标准库中找到：的std :: COUT 在标准中定义为的extern ostream的COUT; 等 COUT 基本需要的的东西的（库或的资源文件）声明它的一次且仅一次分配。
Some examples can also be found in the standard library: std::cout is defined in the standard as extern ostream cout;, and so cout basically requires the distribution of something (library or sourcefile) that declares it once and only once.
这篇关于为什么不是所有的Boost库仅邮件头？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
