基本上,你的问题可以归结为“在C++开源项目中使用[免费库xyz]作为依赖项是否合理”。
现在考虑斯特劳斯特鲁普(Stroustrup)的以下引用,答案显而易见:
没有好的库,大多数有趣的任务在 C++ 中都很难完成;但是如果有了好的库,几乎任何任务都可以变得容易。
假设这是正确的(根据我的经验,它确实如此),那么编写一个合理大小的 C++ 项目 没有 依赖关系是完全不合理的。
进一步发展这个论点,唯一可能在(开发人员的)客户端系统上合理预期的 C++ 依赖项(除了系统库)是 Boost 库。 我知道它们不是,但对于软件来说,这并不是一个不合理的推断。
如果软件甚至不能依赖 Boost,那么它就不能依赖于任何库。
“bcp实用程序是提取Boost子集的工具,对于希望将其库与Boost分开分发的Boost作者以及希望使用应用程序的Boost用户来说非常有用。当然,这种方法可能会有一些缺点-但至少您应该意识到可以这样做。bcp还可以报告代码依赖于Boost的哪些部分,以及这些依赖项使用的许可证。”
KDE也依赖于Boost。
然而,它主要取决于您的目标受众,而不是项目的范围。例如,TinyJSON(非常小的项目)几乎100%依赖于Boost,但这没关系,因为它提供的API类似于Boost,并针对需要JSON绑定的Boost程序员。然而,许多其他JSON库不使用Boost,因为它们面向其他受众。
另一方面,在工作中我不能使用Boost,我知道很多其他开发人员(在他们的日常工作中)也是如此。因此,如果您的目标是OpenSource和使用Boost的群体,请继续前进。如果您的目标是企业,则可能需要仔细考虑并从Boost中复制粘贴必要的部分(并承诺支持),以使您的项目正常工作。
这要看情况。如果你在使用Boost中只定义了头文件的类模板,那么可以放心使用,因为它不会引入任何Boost共享库,所有代码都是在编译时生成的,没有外部依赖。版本问题对于任何共享C++库来说都是一个痛点,Boost也不例外,所以如果你能完全避免这个问题,那就是一件好事。
我认为Boost提供的广泛功能,正如你所说,它是标准非标准的C++库,这使得它成为一种依赖。
很不幸,对于Ubuntu来说,它们很容易获得,但是对于RHEL 4&5,我几乎总是需要从tarballs中制作它们。它们是很棒的库,只是非常大...就像有时候你只需要图钉,而不是铁路钉。
这完全取决于你使用Boost的方式。正如Diomidis所说,如果你要使用一些非常规的Boost设施,那就,请上吧!使用库不是一种罪过。
当然,有很多人不想用Boost,因为引入新依赖项总是会带来一些缺点和额外的担忧,但在一个开源项目中......我认为,如果你只是想学习它们或提高自己的技能,使用它们甚至是可以接受的。