Boost旨在成为每个C ++用户都可以使用的标准非标准C ++库。假设它可用于开放源C ++项目是否合理，或者它是否过于依赖大型对象？

解决方案

我会说是的。 Mandriva(基于Red Hat)和Ubuntu(基于Debian)都具有Boost库的软件包。

不幸的是，对于ubuntu来说，它们很容易获得，但是对于RHEL 4＆5，我几乎总是以tarball制作它们。它们是很棒的库，真的很大……就像有时需要的只是图钉时使用铁路钉。

KDE也依赖Boost。

但是，这主要取决于目标，甚至还取决于目标受众，而不是项目范围。例如TinyJSON(非常小的项目)几乎是100％Boost，但这很好，因为它提供的API类似于Boost，并且针对需要JSON绑定的Boost程序员。但是，许多其他JSON库不使用Boost，因为它们针对其他受众。

另一方面，我不能在工作中使用Boost，而且我知道很多其他开发人员(在他们的日常工作中)都在同一条船上。因此，我想我们可以说，如果Target是OpenSource，并且一个使用Boost的小组，请继续。如果我们以企业为目标，则可能需要考虑一下，然后从Boost中复制并粘贴必要的部分(并获得他们的支持)，以使项目正常工作。

• 编辑：之所以不能在工作中使用它，是因为我们的软件必须可移植到大约7个不同的平台和4个编译器中。因此我们不能使用boost，因为尚未被证明与我们的所有目标都兼容，因此原因是技术上的。 (我们对"开放源代码"和" Boost许可"部分感到满意​​，因为我们有时会将Boost用于其他用途)

我曾经非常谨慎地将依赖项引入到系统中，但是现在我发现依赖项并不是什么大问题。现代操作系统附带软件包管理器，这些软件包管理器通常可以自动解决依赖性，或者至少使管理员可以轻松安装所需的软件包。例如，Boost在Gentoo-Postage下可作为dev-libs / boost使用，在FreeBSD端口下可作为devel / boost使用。

现代开源软件在其他系统上构建了很多东西。在最近的一项研究中，通过跟踪FreeBSD软件包的依赖性，我们确定FreeBSD 4.11系统中的12,357个端口软件包总共具有21,135个库依赖性。即，除了基础系统中52个库以外，他们还需要一个库才能进行编译。库依赖项包含688个不同的库，而单个项目使用的不同外部库的数量在1到38之间变化，且模式值为2. 此外，有5117个项目使用了至少一个外部库，而405个项目使用了10个或者更多。

最后，问题的答案将来自成本与收益分析。重用成熟，广泛使用，经过审查和测试的库(例如Boost)的好处是否大于依赖成本的低廉和下降？对于Boost工具的任何不平凡的使用，答案是我们应该继续使用Boost。

这取决于。如果我们在Boost中仅使用头文件定义的类模板，则可以继续使用它，因为它不会吸收任何Boost共享库，因为所有代码都是在编译时生成的，没有外部依赖性。版本问题对于任何共享的c ++库都是一个痛苦，Boost也不能幸免，因此，如果我们可以完全避免该问题，那是一件好事。

看一下http://www.boost.org/doc/tools.html。特别是，如果我们想将boost-dependencies嵌入到项目中，则bcp实用程序将派上用场。网站摘录：

"The bcp utility is a tool for extracting subsets of Boost, it's useful for Boost authors who want to distribute their library separately from Boost, and for Boost users who want to distribute a subset of Boost with their application.bcp can also report on which parts of Boost your code is dependent on, and what licences are used by those dependencies."

当然，这可能会有一些缺点，但是至少我们应该意识到这样做的可能性。

基本上，问题归结为[免费库xyz]作为C ++开源项目的依赖项是否合理。

现在考虑以下来自Stroustrup的报价，答案确实是显而易见的：

Without a good library, most interesting tasks are hard to do in 
  C++; but given a good library, almost any task can be made easy

假设这是正确的(以我的经验，是这样)，那么编写一个大小合理且没有依赖关系的C ++项目是完全不合理的。

进一步发展该论点，可以合理地期望在(开发人员)客户端系统上的一个C ++依赖关系(系统库除外)是Boost库。
我知道它们不是，但这并不是软件制造的不合理假设。

如果软件甚至不能依赖Boost，那么它就不能依赖任何库。

这完全取决于我们使用Boost的方式。正如Diomidis所说，如果我们要使用Boost的一些非凡功能，那就继续吧。使用图书馆不是犯罪。

当然，有很多人不喜欢使用Boost，因为引入新的依赖项总是有一些弊端和额外的烦恼，但是在一个开源项目中……在我看来，如果我们只是想学习，就可以使用它们他们或者提高他们的技能。

我认为Boost提供了广泛的功能，正如我们所说的，它是标准的非标准C ++库证明了它是依赖项。

在编写C ++代码时使用boost的好处是，它们大大超过了分发开放源代码的额外复杂性。

我在程序员的记事本上工作，代码依赖于boost来进行测试，智能指针和python集成。由于有一些要求，因此有一些抱怨，但是如果他们想处理代码，大多数人只会继续抱怨。接受增强依赖是我从未后悔过的决定。

为了使其他程序的复杂性略为降低，我包括了用于Boost python的预构建版本库，因此他们所需要做的就是在include目录中提供boost。