为什么人们似乎在暗示我不愿使用Boost？

Question

在 Stack Overflow 上，经常会看到关于 Boost 的笔记，比如：

  

如果你可以使用 Boost...

或者

  

如果你愿意使用 Boost...

我想知道这是怎么回事？我应该注意什么呢？什么时候不能使用 Boost？不使用 Boost 的原因是什么？在我看来，Boost 是 STL 的一个很好的扩展；有时非常笨重和不灵活，但仍然很棒。

我并不是真正询问 Boost 的意见。我更想找一些具体的例子，在使用 Boost 之前，应该三思而后行。

- Jendas

---

有时非常笨重和不灵活。你自己已经回答了这个问题。 - Hatted Rooster

有时候非常笨重和笨拙可能是小型系统的好理由。 - πάντα ῥεῖ

@Jendas 主要是的。但对于小程序，我倾向于避免使用boost库。 - πάντα ῥεῖ

Boost不是一个库，而是一个由大量独立的高质量库组成的集合。其中一些库在C++11中也变得多余了。除此之外，使用第三方库时需要注意一些常见的警告。 - Christian Hackl

@Jongware：或者使用C++标签给出std::sort。 - Lightness Races in Orbit

Answer 1

当我不能使用boost时？在我看来，boost是STL的很好的扩展，有时非常笨重和累赘，但仍然很棒。Boost不是一个库，而是一个由大部分相互独立的高质量库组成的集合。考虑到这一点，并且也考虑到我个人非常喜欢大多数Boost，以下是我认为不适用于某些Boost库的原因：

• 一些Boost库自C++11以来已经冗余了。
• 一些库并没有被广泛使用，因此需要在项目中拥有专业知识，可能会在员工离开公司时变得昂贵。
• 公司的指南，开发人员必须遵守，原因更多是出于政治而不是技术方面。
• 您无法保证任何Boost库将在未来继续维护。为某些编译器编写的标准C++代码今天很可能会在10年后由同一供应商的更新编译器上正常工作，出于简单的商业原因。对于Boost，您必须希望足够能力的人有兴趣进行长期维护。
• 没有任何一种Boost库像C++标准库那样广泛地记录，有如此多的无数书籍和互联网资料。如果您遇到某个特定库的真正奇异问题，谁会支持您？毫无疑问，在标准C++中，您找到具有相同问题（和现有问题解决方案）的人的机会要高得多。
• 调试一些Boost代码可能比调试使用标准库的代码更加困难。

- Christian Hackl

---

基本上我从来没有看到有人推荐boost而不是标准库，除了一些特定的可移植性边缘情况。所以我觉得你提到的原因后半部分都不适用。 - Mooing Duck

@MooingDuck：你基本上可以使用标准库重新发明几乎任何Boost库，使用自己的代码。例如，你可以使用自己的字符串算法库代替Boost的字符串算法，使用<string>和<algorithm>中可用的内容。C++11的lambda表达式使这比以前更容易。我不是在谈论所有直接替换C++11带来的东西（例如std::shared_ptr与boost::shared_ptr）。 - Christian Hackl

或许也可以将构建时间作为参数添加进去。这些 Boost 库必须在许多编译器上工作，而您所提供的标准库只适用于它所附带的编译器。从监视 Boost 代码来看，这似乎并不是一项简单的任务。我们正在用 std 替换 Boost 代码，但实际上我更希望有更多的 Boost 库能够成为 std（例如 calltraits、date-time、graph、signals、io_state saver、string algo、tribool.container）。 - gast128

在Boost库和STL之间明确冗余可能是有趣的。 - kingsjester

Answer 2

因为Boost不是C++标准库（当然也不是STL）的扩展，它是必须下载和安装的第三方分发。对于某些Boost库，如果你使用动态链接，你必须在本地和目标系统上管理并记录依赖关系。我不会列举所有这不可行的情况，但显而易见的是，你不能总是使用非标准代码。并不是每个人都在一个平台上工作，你可以简单地写“yum install boost-devel”，编写代码并继续前进。计算机的世界远远超出了商品桌面PC的范围。

话虽如此，大多数避免使用Boost的论点都是非常脆弱的，因为它极其便携，并且大多数Boost库都是头文件（这显著降低了包装开销）。

引用：“似乎为了什么事情而过度热闹”

我认为写上“如果你能使用Boost”这句话，不能被诚实地描述为“非常热闹”。

- Lightness Races in Orbit

---

@Dúthomhas：“同一批人”这个说法有点过了。 - Christian Hackl

@Dúthomhas：但是http://www.boost.org/community/index.html上说：“尽管Boost最初由C++标准委员会库工作组的成员发起，但参与者已经扩展到包括来自C++社区的数千名程序员。” - Christian Hackl

LOL。很好的挑选。那这个怎么样：“Boost.org和C++标准委员会之间有正式关系吗？”“没有，尽管许多委员会成员参与了Boost，并且创立Boost的人都是委员会成员，因此存在强烈的非正式关系。”或者这个：“我们旨在建立‘现有实践’并提供参考实现，以使Boost库适合最终标准化。” - Dúthomhas

@Dúthomhas：没有人对你有“愤怒”，也没有必要变得防御。冷静点。我坚持认为，它的政治地位作为“不仅仅是另一个C++库”与是否可以使用它相关的技术考虑无关。 - Lightness Races in Orbit

我改正了。对不起大家。 - Dúthomhas

Answer 3

主要是维护。

一旦您添加了提升功能，就必须对其进行维护。 要么获取更新（并维护任何需要更改代码的更改），要么冻结版本并自行修复错误。

这两种方法都很昂贵且成本后置。 对于寿命以十年计的项目来说，这些成本非常重要。

- Yakk - Adam Nevraumont

---

但这对你使用的任何库来说都是真实的。此外，boost是一个古老而广泛使用的库，经过广泛测试 - 至少那些不是刚刚加入的东西，因此你不太可能需要更新boost，除非是为了获得新功能。 - einpoklum

“但这对你使用的任何库都是适用的。” 是的，在同样的情况下，我期望看到短语“如果你可以使用<库名称>”。所以我不认为这是舍弃它的理由！事实上，答案就是Boost库在这个意义上与“你使用的任何库”没有区别。 - Lightness Races in Orbit

@einpoklum 这个问题也随着库的规模而扩大。小而狭窄的库有较少需要审核的内容（这个组件稳定吗？），并且在你更新它时，往往有较少的依赖关系。Boost 可能会遍布你的整个项目，升级以解决网络代码中的问题可能会导致你的项目中其他地方的基于精神的解析代码出现问题（或者至少需要一次审核以确保不会出错）。 - Yakk - Adam Nevraumont

Answer 4

除了 @LightnessRacesInOrbit 的观点外，我认为还有几个原因：

1. Boost 在 .h 和 .hpp 文件中有大量的代码，每个翻译单元（使用 Boost 相关部分）都需要包含这些文件，并且这些文件使用了复杂和递归的宏以及智能（但同样复杂）的模板。这种组合会使您的编译速度变得非常慢。
2. Boost 并不是默认安装在每个地方的，因此它并不总是可用于您所使用的 C++ 和标准 C++ 库。
3. （实际上是一个新的原因）相当一部分的 Boost 功能已经被加入到 C++11 中（更多的在 C++14 中，甚至在 C++17 中也有更多）。因此，现在标准库甚至语言本身已经提供了 Boost 所提供的部分替代品。

- einpoklum

---

嗯，我认为“你不必使用Boost”并不等同于“由于x、y、z原因，你不能使用Boost”。 - Lightness Races in Orbit

广告1：您不需要包含所有内容。您只需要包含您正在使用的内容。大多数较大的功能也被分解为更小的功能，因此您不需要使用大型头文件来处理简单的单个任务。 - AgainPsychoX

@PsychoX：你不需要把它们全部都包含进来，但如果你只包含其中一个，就会带来很多东西；此外，Boost的使用可能会有点像病毒一样传播，有好有坏。 - einpoklum