提升C ++开源项目的依赖性？

Question

Boost意味着 标准的非标准C ++库，每个C ++用户都可以使用。假设它可用于开源C ++项目，或者它是一个很大的依赖性，这是否合理？

Answer 1

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

现在考虑一下Stroustrup的以下引用，答案真的很简单：

  

如果没有一个好的图书馆，最有趣的任务很难做到   C ++;但是如果有一个好的图书馆，几乎任何任务都可以轻松完成

假设这是正确的（根据我的经验，这是正确的）然后编写一个合理大小的C ++项目没有依赖项是完全不合理的。

进一步发展这个论点，在（开发人员）客户端系统上可以合理预期的一个 C ++依赖（除了系统库）是Boost库。 我知道他们不是，但这不是对软件的无理推定。

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

Answer 2

看看http://www.boost.org/doc/tools.html。具体来说，如果您希望将boost-dependencies嵌入到项目中， bcp 实用程序会派上用场。网站摘录：

“bcp实用程序是一个用于提取Boost子集的工具，它对于想要分别从Boost分发其库的Boost作者以及想要使用其应用程序分发Boost子集的Boost用户非常有用。

bcp还可以报告您的代码所依赖的Boost部分，以及这些依赖项使用的许可证。“

当然这可能有一些缺点 - 但至少你应该知道这样做的可能性。

Answer 3

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

现代开源软件在其他系统上构建了很多。在recent study中，通过跟踪FreeBSD软件包的依赖关系，我们确定了FreeBSD 4.11系统中的12,357个端口软件包，共有21,135个库依赖项;也就是说，为了编译，他们需要一个库，而不是作为基本系统一部分的52个库。库依赖项包含688个不同的库，而单个项目使用的不同外部库的数量在1到38之间，模式值为2.此外，5,117个项目至少使用一个外部库，405个项目使用10个或更多。

最后，您的问题的答案将来自成本与收益分析。重用一个成熟的，广泛使用的，经过审查和测试的库（如Boost）的好处是否大于依赖的低成本和低成本？对于任何非常重要的Boost设施使用，答案是你应该继续使用Boost。

Answer 4

KDE也取决于Boost。

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

另一方面，我不能在工作中使用Boost，而且我知道很多其他开发人员（在他们的日常工作中）都在同一条船上。所以我猜你可以说你的Target是OpenSource，还是一个使用Boost的组，请继续。如果您以企业为目标，您可能需要仔细考虑并复制粘贴Boost中的必要部分（并提交他们的支持），以使您的项目能够正常运行。

• 编辑：我们无法在工作中使用它的原因是因为我们的软件具有 可移植到大约7种不同的 平台和4个编译器。所以 我们不能使用提升，因为它没有 已被证明与之兼容 我们所有的目标，所以原因是一个 技术一。 （我们很好 OpenSource和Boost许可证部分， 因为我们在其他方面使用Boost 倍）

Answer 5

这取决于。如果您在Boost中使用头文件仅定义了类模板 - 那么请继续使用它，因为它不会吸入任何Boost共享库，因为所有代码都是在编译时生成的，没有外部依赖。版本控制问题对于任何共享的c ++库来说都是一种痛苦，而Boost并不能免于此，所以如果你能完全避免这个问题，那就是好事。

Answer 6

我会说是的。 Mandriva（基于Red Hat）和Ubuntu（基于Debian）都包含Boost图书馆的软件包。

Answer 7

在编写C ++代码时使用boost的好处远远超过分发开源代码的额外复杂性。

我在Programmer's Notepad上工作，代码依赖于测试，智能指针和python集成的boost。由于这个要求，有一些投诉，但如果他们想要处理代码，大多数人都会继续投诉。采取提升依赖是我从未后悔的决定。

为了使其他人的复杂性略微降低，我为boost python添加了版本化的预构建库，这样他们所需要做的就是在include目录中提供提升。

Answer 8

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

Answer 9

不幸的是，对于ubuntu，它们很容易获得，但是对于RHEL 4和5，我几乎总是最终用tarball制作它们。他们是伟大的图书馆，真的很大......就像使用铁轨尖峰一样，有时你真正需要的只是一个图钉。

Answer 10

这完全取决于你使用Boost的方式。正如迪奥米迪斯所说，如果你打算使用Boost的一些非平凡的设施，那就继续吧。使用图书馆不是犯罪。

当然，有很多人不喜欢使用Boost，因为引入新的依赖关系总是有一些缺点和额外的担忧，但在一个开源项目中......在我看来，如果你只是使用它们甚至可以想要学习它们或提高你的技能。