为什么人们似乎暗示我宁愿不使用 Boost？ [关闭]答案

【问题标题】：Why do people seem to insinuate I would rather not use Boost? [closed]为什么人们似乎暗示我宁愿不使用 Boost？ [关闭]
【发布时间】：2015-10-31 14:55:01
【问题描述】：

我经常在这里看到关于提升的注释，例如

如果你对使用 Boost 没问题...

或

如果你可以使用 Boost...

我想知道，这到底是怎么回事？我应该厌倦什么？当我不能使用 boost？不使用boost的原因是什么？在我看来，boost 是对 STL 的一个很好的扩展。有时非常重量级和笨拙，但仍然很棒。

我并不是真的在征求关于 boost 的意见。我宁愿寻找一些具体的例子，在使用 boost 之前我应该三思而后行。

【问题讨论】：

sometimes very heavyweight and clumsy 你回答了你自己的问题。
“有时非常重量级和笨拙”可能是小型系统的好理由。
就这样？似乎有很多无用的模糊：-/您所说的小型系统是指嵌入式系统等？
Boost 不是一个库，而是一个大部分独立库的集合，具有各自的质量。从 C++11 开始，它们中的一些也是多余的。除此之外，适用于 3rd 方库的常见警告。
@Jongware：或者std::sort，给定C++标签。

标签： c++ boost c++-standard-library

【解决方案1】：

什么时候我不能使用 boost？在我看来，boost 是对 STL 的很好的扩展，有时非常重量级和笨拙，但仍然很棒。

Boost 不是一个库，而是一个大部分独立库的集合，具有各自的品质。考虑到这一点，并且考虑到我个人是大多数 Boost 的忠实粉丝，以下是我能想到的不使用某些 Boost 库的一些原因：

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

【讨论】：

我基本上没有看到有人推荐 boost 而不是标准库，除了一些特定的可移植性边缘情况。所以我觉得你的后半部分理由都不适用。
@MooingDuck：嗯，你基本上可以使用标准库，用你自己的代码重新发明几乎所有的 Boost 库。例如，您可以使用自己的字符串算法库而不是 Boost 的字符串算法，使用 <string> 和 <algorithm> 中可用的内容。 C++11 lambda 使这比以前更容易。我不是在谈论 C++11 附带的所有直接替换（例如 std::shared_ptr 与 boost::shared_ptr）。
也许也可以添加构建时间作为参数。这些 Boost 库必须在许多编译器上工作，而您提供的标准库仅适用于它附带的编译器。监视 Boost 代码似乎不是一件容易的事。我们正在用 std 替换 Boost 代码，但实际上我希望更多的 Boost 库成为 std（例如 calltraits、date-time、graph、signals、io_state saver、string algo、tribool.container）

【解决方案2】：

因为它不是对 C++ 标准库的扩展（自然也不是对 STL）。

它是一个第三方发行版，您必须在本地和（对于某些 Boost 库，如果您动态链接）在目标系统上下载和安装。您必须管理和记录依赖关系。

我不会列举不可行的所有场景，但不言而喻，您不能总是使用非标准代码。不是每个人都在一个平台上工作，您可以在该平台上简单地编写yum install boost-devel，编写代码并继续前进。计算机的世界远远超出了商用台式电脑。

话虽如此，由于 Boost 具有极高的可移植性，而且大多数 Boost 库都是仅标头（这大大减少了打包开销），因此大多数避免使用 Boost 的论点都非常薄弱。

似乎有很多无用的绒毛

我不认为写这句话“如果你可以使用 Boost” 可以诚实地描述为“很多 [大惊小怪]”。

【讨论】：

但 Boost 是改进标准库的场所。同一个人同时维护两者。
@Dúthomhas：“同一个人”真的有点过分了。
@Dúthomhas：但boost.org/community/index.html 说：“尽管 Boost 是由 C++ 标准委员会库工作组的成员发起的，但参与范围已经扩大到包括来自整个 C++ 社区的数千名程序员。”
哈哈。采樱桃不错。这个怎么样：“Boost.org 和 C++ 标准委员会之间有正式的关系吗？ 没有，尽管委员会的许多成员都参与了 Boost，所以有很强的非正式关系"
@Dúthomhas：没有人对你有“愤怒”，没有必要采取防御措施。冷静下来。而且我坚持认为，它作为“不仅仅是另一个 C++ 库”的政治地位与围绕你是否可以使用它的决定的技术考虑无关。

【解决方案3】：

主要是维护。

一旦你添加了提升，你必须保持它。要么获取更新（并维护任何强制更改代码的更改），要么冻结版本并自行修复错误。

两者都是昂贵且后置的成本。对于一个生命周期以几十年来衡量的项目来说，这样的成本非常重要。

【讨论】：

但这对于您使用的任何库来说都是如此，基本上。另外，boost 是旧的，广泛使用的东西是经过广泛测试的 - 至少是那些不只是制造出来的东西，所以除了获得新功能之外，你不太可能需要更新 boost。
@ein “但对于您使用的任何库都是如此” 对，在同样的场景中，我希望看到“如果您可以使用 ”。所以我不认为这是放弃这个的理由！实际上，答案是，至少在这个意义上，Boost 库与“您使用的任何库”没有什么不同。
@einpoklum 这个问题也随着图书馆的规模而扩大。一个小而窄的库需要审计的东西更少（这个组件稳定吗？），并且当您更新它时，项目中的依赖项往往会更少。 Boost 可以很容易地遍布您的项目，并且升级以解决网络代码的问题可能会破坏您项目中其他地方的基于精神的解析代码（或者，至少需要审核以确保它不会破坏） .

【解决方案4】：

除了@LightnessRacesInOrbit 的point，我想说还有几个原因：

Boost 在.h 和.hpp 文件中有很多代码，您需要将这些代码包含在每个翻译单元（使用Boost 的相关部分）中，而这些文件已经满载具有复杂和递归的宏使用以及智能（但同样复杂）的模板使用。这种组合会使您的编译速度慢很多。
默认情况下，Boost 并未安装在任何地方，因此它并不总是可供您使用，因为 C++ 和标准 C++ 库是。
（实际上是一个新原因）相当大一部分 Boost 功能已进入 C++11（更多的是在 C++14 中，更多的是在 C++17 中）。因此，到目前为止，标准库甚至语言本身都存在替代方案，可作为 Boost 提供的部分功能。

【讨论】：

嗯，我不认为“你没有有使用Boost”等同于“你不能使用Boost [对于 x, y, z] 原因"
Ad.1 您不需要包括所有这些。您只需要包括您正在使用的那些。大多数较大的功能也被分解成较小的功能，因此您无需使用大型头文件来处理简单的单个任务。
@PsychoX：你不需要把它们都包括在内，但如果你只包括一个，你就会吸引很多；另外，无论好坏，Boost 的使用都会变得有点流行。