【问题标题】:What does Boost mean by "header-only libraries" and "automatic linking"?Boost 中的“仅标头库”和“自动链接”是什么意思?
【发布时间】:2012-07-30 23:08:30
【问题描述】:

Boost library documentation 页面上,有两个类别分别名为“Header Only Libraries”和“Automatic Linking”。

我想“仅标题库” 意味着您不必链接到 Boost 库即可使用它们,“自动链接” 意味着您必须链接。

但是当我使用Boost.Timer时,我必须链接一个名为timer的静态或动态库(libboost_timer.alibboost_timer.so.1.48.0以及Linux库路径下的各种软链接),这显然是确切的库Boost.Timer 的文件。我什至需要链接Boost.SystemBoost.Chrono,尽管库本身使用了一些其他需要链接的库是可以理解的。

另一方面,Boost 已经明确表示Boost.Asio 属于“自动链接”,但没有任何类似asio 的库文件。

那么,“仅标头库”或“自动链接”究竟意味着什么?还是纯粹是个错误?

【问题讨论】:

标签: c++ boost header linker


【解决方案1】:

正如您所说,“仅头文件库”意味着整个库都在头文件中,因此一个(或多个)#include 行足以使用它。不需要链接。

“自动链接”的意思是,虽然库需要一些链接(直接或作为依赖项),但您不需要在编译器行中指定它,因为#include'd 文件会做一些魔术如果编译器支持,自动引入适当的库。

例如,在MSVC 编译器中,它们使用#pragman comment(lib, "...");在 Borland 编译器中,他们使用 #pragma defineoptions; 等。

最值得注意的是,GNU 编译器支持“自动链接”。

自动链接有时会很麻烦(例如,混合调试和发布版本),您可以通过定义一些预处理器宏来选择性地禁用它们:BOOST_<libname>_NO_LIB。在这种情况下,您将不得不手动进行链接。

更新:关于您的评论如下:

Boost.Timer 声称是“仅标头库”,但它在 lib 目录中有 lib 文件。

Boost documentation 中似乎有错误。实际上有两个名为 timer 的不同库:旧的、已弃用的、仅标头的 <boost/timer.hpp> 和新的、改进的、更酷的、可自动链接的 <boost/timer/timer.hpp>

但由于某种原因,主文档页面列出了旧版本的属性。

没有Boost.Asio lib 文件。

在主 Boost 库文档页面 library documentation page 中,您可以看到 Asio 被列为 Automatic linking due to dependency。列出了具体的依赖项elsewhere:Boost.System 和 Boost.Regex,并且都存在自动链接。

【讨论】:

  • 您能解释一下为什么Boost.Timer 声称是“仅标头库”在 lib 目录中有 lib 文件吗?而且没有Boost.Asio lib 文件。
  • 在该库文档页面上无法再找到有关 Asio 依赖状态的信息。现在是否有任何页面包含这些信息?
  • @rwst:我不明白你的意思。最新的docs 包含更新的信息。
【解决方案2】:

您已经成功了 - 仅标头库是该库的所有代码都包含在标头中的库,因此您只需包含它们,而不是链接到库即可使用它们.

也就是说,完全有可能编写一个依赖于某些 other 库的仅标头库,这些库可能属于仅标头种类。在这种情况下,即使您不必告诉链接器您正在使用的 first 库,您仍然必须告诉它第二个。尤其是当/如果所有代码都可能被塞进链接器认为的库之一(例如,一个 .lib 或 .a 文件)中时,这可能最终主要是没​​有区别的区别(只是要清楚: 这里不一定是这种情况,但无论如何它都会而且确实会出现)。

【讨论】:

  • @WiSaGaN:是的。 Boost 是库的集合,而不是单个库。大多数 Boost 库都是只有头文件的。但是,一些 Boost 库(例如 Boost.Thread)具有单独的源文件,这些文件被编译成您需要链接到的目标代码。
  • @Insilico 是的,我明白这一点。奇怪的是Header Only 的声明和lib 文件之间的明显矛盾(以及Automatic Linking 的声明和没有lib 文件之间的矛盾)。
  • @WiSaGaN:是的,可移植的开源库往往是这样的……如果您找到一个非常用户友好且具有预构建二进制文件的库,那么它并不“酷”。你不能从头开始构建它们并经历痛苦。或者至少这是我从迄今为止使用的那些中得到的印象。
  • boost 的库是在安装后手动构建的。所以我猜这不是编译器的问题。
  • @CodyGray,JerryCoffin:伤害?好吧,如果您不认为浪费时间是有害的,那么我想也许不会。 :\ 说到这——它让我想起了工具 bcp 也不是二进制分发的。让客户端编译这些真的没有意义。它所做的只是让图书馆成为用户界面的灾难。但我猜想围绕可移植开源工具的假设是用户界面是为最终用户服务的,而不是为程序员服务的。 :(
猜你喜欢
  • 1970-01-01
  • 2010-09-23
  • 2015-08-26
  • 2013-11-18
  • 1970-01-01
  • 2012-05-07
  • 1970-01-01
  • 2010-12-27
相关资源
最近更新 更多