Boost旨在成为每个C++用户都可以使用的标准非标准C++库。假设它对于开源C++项目可用，这合理吗？或者说它是一个太大的依赖关系？
10个回答
45
基本上，你的问题可以归结为“在C++开源项目中使用[免费库xyz]作为依赖项是否合理”。
现在考虑斯特劳斯特鲁普（Stroustrup）的以下引用，答案显而易见：
没有好的库，大多数有趣的任务在 C++ 中都很难完成；但是如果有了好的库，几乎任何任务都可以变得容易。
假设这是正确的（根据我的经验，它确实如此），那么编写一个合理大小的 C++ 项目 没有 依赖关系是完全不合理的。
进一步发展这个论点，唯一可能在（开发人员的）客户端系统上合理预期的 C++ 依赖项（除了系统库）是 Boost 库。 我知道它们不是，但对于软件来说，这并不是一个不合理的推断。
如果软件甚至不能依赖 Boost，那么它就不能依赖于任何库。
- Konrad Rudolph
9
2如果大部分文件很小，我猜我不想使用它们。我见过的文件相互关联，以至于它们使我们的代码tarball膨胀了数十兆字节。我们向客户发送代码，他们希望能够在多个Linux发行版上进行编译。版本之间的变化太多，不能简单地告诉我们的客户boost是先决条件。由于boost的巨大大小，我们无法将其与我们的代码捆绑在一起。Boost库开发人员似乎从未考虑限制代码大小。例如，boost_1_49_0/boost/typeof/vector200.hpp是一个超过2MB的源文件。 - Mark Borgerding
如果一个软件甚至不能依赖于Boost，那么它就不能依赖于任何库。我刚刚检查了标准的Boost发行版，其中包含大约40,000个源文件...这是一个相当庞大的依赖关系！ - Tom Swirly
@TomSwirly 你有没有计算过其他框架的大小？此外，Boost非常模块化。除了许多库只是头文件 - 这意味着您可以将必要的头文件放入项目中 - 所有库都可以单独安装。承认，Boost 可能会使这更容易，但安装所有Boost绝对是直截了当的，并且分发其二进制文件也是如此。 - Konrad Rudolph
1我并不是支持或反对使用Boost！我只是说相比于大多数库，这是一个很重的依赖。在我的当前项目中，我有几个其他的依赖项 - 它们的大小加起来只是Boost大小的一小部分。但是，如果你需要它来支持核心功能，那么你真的需要它！因此，答案不是“如果软件甚至不能依赖于Boost，那么它就不能依赖于任何库。”而是“这要取决于情况。” - Tom Swirly
如果一个软件甚至不能依赖于Boost，那么它就不能依赖于任何库。我不同意这种说法。一个软件可以依赖于系统库以及标准的C++库。你在项目中添加的依赖项越多，就会有更多的事情超出你的控制范围。仅仅因为库A在项目B上运行良好，并不意味着更新后它不会在项目C上出现问题。 - rxantos
显示剩余4条评论
28
请查看http://www.boost.org/doc/tools.html。特别是，如果您想将Boost依赖项嵌入项目中，则bcp实用程序会很有用。以下是网站上的一段摘录：
“bcp实用程序是提取Boost子集的工具，对于希望将其库与Boost分开分发的Boost作者以及希望使用应用程序的Boost用户来说非常有用。当然，这种方法可能会有一些缺点-但至少您应该意识到可以这样做。bcp还可以报告代码依赖于Boost的哪些部分，以及这些依赖项使用的许可证。”
- Subtwo
13
我曾经非常警惕引入系统依赖，但现在我发现依赖关系并不是什么大问题。现代操作系统配备了软件包管理器，通常可以自动解决依赖关系，或者至少让管理员轻松安装所需的软件包。例如，在Gentoo-Postage下Boost可作为dev-libs/boost，在FreeBSD ports下可作为devel/boost。
现代开源软件大量依赖其他系统。通过跟踪FreeBSD软件包的依赖关系，我们在最近的一项研究中确定，在我们的FreeBSD 4.11系统中的12,357个端口软件包中，总共有21,135个库依赖项；即，它们需要一个库来编译，而这个库不属于基本系统的52个库之一。这些库依赖项包括688个不同的库，而单个项目使用的外部库数量在1到38之间变化，众数为2。此外，5,117个项目使用了至少一个外部库，405个项目使用了10个或以上。
最终，对于你的问题的答案将来自成本与效益分析。重用像Boost这样成熟、广泛使用、经过审查和测试的库是否比依赖关系的低且逐渐降低的成本更有利？对于任何使用Boost工具的非微不足道的用途，答案是应该继续使用Boost。
现代开源软件大量依赖其他系统。通过跟踪FreeBSD软件包的依赖关系，我们在最近的一项研究中确定，在我们的FreeBSD 4.11系统中的12,357个端口软件包中，总共有21,135个库依赖项；即，它们需要一个库来编译，而这个库不属于基本系统的52个库之一。这些库依赖项包括688个不同的库，而单个项目使用的外部库数量在1到38之间变化，众数为2。此外，5,117个项目使用了至少一个外部库，405个项目使用了10个或以上。
最终，对于你的问题的答案将来自成本与效益分析。重用像Boost这样成熟、广泛使用、经过审查和测试的库是否比依赖关系的低且逐渐降低的成本更有利？对于任何使用Boost工具的非微不足道的用途，答案是应该继续使用Boost。
- Diomidis Spinellis
4
KDE也依赖于Boost。
然而，它主要取决于您的目标受众，而不是项目的范围。例如，TinyJSON（非常小的项目）几乎100％依赖于Boost，但这没关系，因为它提供的API类似于Boost，并针对需要JSON绑定的Boost程序员。然而，许多其他JSON库不使用Boost，因为它们面向其他受众。
另一方面，在工作中我不能使用Boost，我知道很多其他开发人员（在他们的日常工作中）也是如此。因此，如果您的目标是OpenSource和使用Boost的群体，请继续前进。如果您的目标是企业，则可能需要仔细考虑并从Boost中复制粘贴必要的部分（并承诺支持），以使您的项目正常工作。
- 编辑：我们无法在工作中使用它的原因是因为我们的软件必须可移植到大约7个不同的平台和4个编译器。因此，我们不能使用Boost，因为它还没有被证明与我们所有目标兼容，所以原因是技术性的。（我们对OpenSource和Boost License部分感到满意，因为有时我们也会使用Boost进行其他操作）
- Robert Gould
3
1我很好奇为什么你不能在工作中使用它，是担心开源风险吗？还是有其他技术原因？ - dajobe
2我认为Boost库经常在大约12个系统和10212个编译器上进行测试（当然这是夸张的）。但我知道他们在很多系统上进行了大量测试。 - Raindog
是的，Boost在大多数平台上表现很好，但对于关键的嵌入式设备（如军事和医疗设备）以及许多游戏机（我的情况），无法保证它能正确地工作（有时会在某些平台上出现故障）。 - Robert Gould
4
这要看情况。如果你在使用Boost中只定义了头文件的类模板，那么可以放心使用，因为它不会引入任何Boost共享库，所有代码都是在编译时生成的，没有外部依赖。版本问题对于任何共享C++库来说都是一个痛点，Boost也不例外，所以如果你能完全避免这个问题，那就是一件好事。
- jeramiah
4
使用boost编写C++代码的好处远远超过了分发开源代码时所需的额外复杂性。
我在程序员记事本上工作，该代码对测试、智能指针和Python集成有依赖于boost。虽然由于这种要求而投诉过几次，但大多数人只要想在代码上工作，就会继续下去。使用boost是我从未后悔过的决定。
为了让其他人的复杂性稍微减少一些，我包含了版本化的预构建boost python库，这样他们只需要提供boost在其包含目录中即可。
我在程序员记事本上工作，该代码对测试、智能指针和Python集成有依赖于boost。虽然由于这种要求而投诉过几次，但大多数人只要想在代码上工作，就会继续下去。使用boost是我从未后悔过的决定。
为了让其他人的复杂性稍微减少一些，我包含了版本化的预构建boost python库，这样他们只需要提供boost在其包含目录中即可。
- Simon
2
我认为Boost提供的广泛功能，正如你所说，它是标准非标准的C++库，这使得它成为一种依赖。
- dinomite
1
很不幸，对于Ubuntu来说，它们很容易获得，但是对于RHEL 4&5，我几乎总是需要从tarballs中制作它们。它们是很棒的库，只是非常大...就像有时候你只需要图钉，而不是铁路钉。
- David
1
这完全取决于你使用Boost的方式。正如Diomidis所说，如果你要使用一些非常规的Boost设施，那就，请上吧！使用库不是一种罪过。
当然，有很多人不想用Boost，因为引入新依赖项总是会带来一些缺点和额外的担忧，但在一个开源项目中......我认为，如果你只是想学习它们或提高自己的技能，使用它们甚至是可以接受的。
- David A.G.
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接