Boost 旨在成为每个 C++ 用户都可以使用的标准非标准 C++ 库。假设它可用于开源 C++ 项目是否合理,或者它是一个太大的依赖关系?
10 回答
基本上,您的问题归结为“将 [free library xyz] 作为 C++ 开源项目的依赖项是否合理。”</p>
现在考虑一下 Stroustrup 的以下引用,答案真的很简单:
如果没有一个好的库,大多数有趣的任务都很难在 C++ 中完成;但是如果有一个好的库,几乎任何任务都可以轻松完成
假设这是正确的(根据我的经验,它是正确的),那么编写一个没有依赖关系的大小合理的 C++ 项目是完全不合理的。
进一步发展这一论点,在(开发人员的)客户端系统上可以合理预期的一个C++ 依赖项(除了系统库)是 Boost 库。我知道他们不是,但这并不是一个软件制作的不合理假设。
如果一个软件甚至不能依赖 Boost,它就不能依赖任何库。
看看http://www.boost.org/doc/tools.html。具体来说,如果您想将 boost-dependencies 嵌入到您的项目中,那么bcp实用程序会派上用场。网站摘录:
“bcp 实用程序是一种用于提取 Boost 子集的工具,它对于希望将其库与 Boost 分开分发的 Boost 作者以及希望将 Boost 子集与他们的应用程序一起分发的 Boost 用户非常有用。bcp 还可以报告您的代码依赖于 Boost 的哪些部分,以及这些依赖项使用了哪些许可证。”
当然,这可能有一些缺点——但至少你应该意识到这样做的可能性。
过去我对向系统引入依赖关系非常谨慎,但现在我发现依赖关系并不是什么大问题。现代操作系统带有包管理器,这些包管理器通常可以自动解决依赖关系,或者至少可以让管理员轻松安装所需的内容。例如,Boost 在 Gentoo-Postage 下作为 dev-libs/boost 可用,在 FreeBSD 端口下作为 devel/boost 可用。
现代开源软件在其他系统上构建了很多东西。在最近的一项研究中,通过跟踪 FreeBSD 包的依赖关系,我们确定在我们的 FreeBSD 4.11 系统中的 12,357 个端口包,总共有 21,135 个库依赖项;即,他们需要一个库,而不是作为基本系统一部分的 52 个库,以便编译。库依赖包含 688 个不同的库,而单个项目使用的不同外部库的数量在 1 到 38 之间变化,众数值为 2。此外,5,117 个项目使用了至少一个外部库,405 个项目使用了 10 个或更多.
最后,您的问题的答案将来自成本与收益分析。重用成熟、广泛使用、经过审查和测试的库(如 Boost)的好处是否大于依赖项的低成本和不断下降的成本?对于 Boost 工具的任何重要用途,答案是您应该继续使用 Boost。
KDE 也依赖于 Boost。
然而,这主要取决于您的目标,甚至更多取决于您的目标受众,而不是您的项目范围。例如 TinyJSON(非常小的项目),几乎是 100% Boost,但这很好,因为它提供的 API 类似于 Boost,并且针对需要 JSON 绑定的 Boost 程序员。然而,许多其他 JSON 库不使用 Boost,因为它们针对的是其他受众。
另一方面,我不能在工作中使用 Boost,而且我知道很多其他开发人员(在他们的日常工作中)都在同一条船上。所以我想你可以说如果你的目标是开源的,并且一个使用 Boost 的小组,请继续。如果您的目标是企业,您可能需要考虑一下,并从 Boost 中复制粘贴必要的部分(并承诺他们的支持),以使您的项目能够正常工作。
- 编辑:我们不能在工作中使用它的原因是因为我们的软件必须可移植到大约 7 个不同的平台和 4 个编译器。所以我们不能使用 boost,因为它没有被证明与我们所有的目标兼容,所以原因是技术问题。(我们对 OpenSource 和 Boost License 部分很好,因为我们有时将 Boost 用于其他事情)
这取决于。如果您在 Boost 中使用仅定义类模板的头文件 - 那么可以继续使用它,因为它不会吸收任何 Boost 共享库,因为所有代码都是在编译时生成的,没有外部依赖项。版本控制问题对于任何共享的 c++ 库来说都是一个痛苦,而 Boost 也不能幸免于此,所以如果你可以完全避免这个问题,那是一件好事。
在编写 C++ 代码时使用 boost 的好处大大超过了分发开源代码的额外复杂性。
I work on Programmer's Notepad and the code takes a dependency on boost for test, smart pointers, and python integration. There have been a couple of complaints due to the requirement, but most will just get on with it if they want to work on the code. Taking the boost dependency was a decision I have never regretted.
To make the complexity slightly less for others, I include versioned pre-built libraries for boost python so that all they need to do is provide boost in their include directories.
我认为 Boost 提供的广泛功能,正如您所说,它是标准的非标准 C++ 库,证明它是一个依赖项。
不幸的是,对于 ubuntu,它们很容易获得,但对于 RHEL 4&5,我几乎总是最终用 tarball 制作它们。它们是很棒的图书馆,真的很大……就像有时你真正需要的只是一个图钉时使用一个铁轨钉。
这完全取决于您使用 Boost 的方式。正如 Diomidis 所说,如果您要使用 Boost 的一些重要设施,那就继续吧。使用图书馆不是犯罪。
当然,也有很多人不喜欢使用 Boost,因为引入新的依赖总是有一些缺点和额外的担忧,但是在一个开源项目中......我认为如果你只是想学习,使用它们甚至可以他们或提高你对他们的技能。