我们应该更喜欢 Boost 还是标准库？ [关闭]答案

【问题标题】：Should we prefer Boost or standard lib? [closed]我们应该更喜欢 Boost 还是标准库？ [关闭]
【发布时间】：2013-01-15 09:50:35
【问题描述】：

我正在阅读 Boost 数组文档，我看到了这一行：

如果你使用 C++11，你应该考虑使用 std::array 而不是 boost::array

我的印象是，对于它的主要库来说，Boost 总是比标准库更可取，因为：

boost 的性能永远不会比标准库差
boost 可能会提供更多功能
boost 的质量终于与标准 lib 相同（编写 C++ 标准的人是积极的 boost 开发人员/主管）
几年后，主要的增强功能最终出现在标准库中

那么我更喜欢 boost 而不是 stdlib 是否正确？

如果不是/更复杂，我的哪些假设需要纠正？

【问题讨论】：

#2 肯定是真的（几乎任何“可能”发生的事情）。＃1是没有根据的，即使在实践中是正确的。 #3 不遵循，也是主观的。 #4 可能是真的，也可能不是，但无论如何在这种情况下并不意味着什么。
我发现使用 boost 库时编译时间可能会更长，因为必须引入大量编译器解决方法文件，而供应商的标准库实现可以仅用于一种编译器实现。
声明的主要部分是“如果您使用的是 C++11”。这是关键，因为 boost 目前是一个 C++03 库。我确信 boost 会为 C++11 开发一些很棒的新版本，并且可能还会有一些新版本，所以 boost 不会完全消失。
@CashCow 不幸的是，情况并非如此。最新的提升需要编译为 C++11 才能解锁所有功能。
#1 是错误的：例如：来自 VS 的 make_shared 具有当时 Boost 所没有的性能优化，它可能是后来添加的

标签： c++ boost

【解决方案1】：

我认为您应该在可用时使用标准库，因为...它是标准的并且随编译器一起提供。此外，如果你使用 boost，你需要一个烦人的外部依赖。

所以，我的建议是：尽可能使用 std。如果您正在编写可移植代码，也必须使用旧编译器编译，您可以考虑使用自己的命名空间（例如：cxx0x），根据您使用的编译器嵌入 std 或 boost 命名空间（这称为 命名空间别名）：

#ifdef COMPILER_HAS_CXX0X
    #include <memory>
    namespace cxx0x = std;
#else
    #include <boost/shared_ptr.hpp>
    namespace cxx0x = boost;
#endif

...

cxx0x::shared_ptr< MyClass > = ...

【讨论】：

那叫命名空间别名。
2013 年了……是时候承认了CXX11
现在是 2014 年，所以... CXX14
现在是 2019 年，所以... CXX17。尤其是 CXX14 中的 std::experimental::filesystem 现在可以在 CXX17 中作为 std::filesystem 使用。
现在是 2020 年，所以 C++20

【解决方案2】：

取自Boost个人：

为什么组织应该使用 Boost？

总之，生产力。用于像 Boost 这样的高质量库加速初始开发，结果更少的错误，减少轮子的再发明和削减长期维护成本。而且因为 Boost 库往往成为 de 事实或法律标准，许多程序员已经熟悉他们。

Boost 库中有 10 个是包含在 C++ 标准库的 TR1，因此被定为以后完整标准化。更多 Boost 库正在为 TR2 准备中。使用 Boost 库提供了一个组织在采用新的技术。

许多组织已经在使用程序使用 Boost 实现，例如 Adobe Acrobat Reader 7.0。

【讨论】：

+1 我总是喜欢例子而不是简单的文字。
这是 Boost 的放大镜。不是像 OP 要求的那样进行比较的好来源。 Boost 启发了一些标准委员会的事实当然是正确的。即使在标准化之后，事实提升仍然是最佳选择。
我在使用 boost 时遇到了很多麻烦。切换到最新版本时意外崩溃（但只有 Release 版本），性能低下，因为您不知道 boost 如何实现某些东西并且您不应该真正关心，等等...如果您可以没有它，请远离它你的生活会稍微好一点。
所以 Boost 人自己建议使用 Boost 是使用未来标准库的垫脚石 - 到目前为止，这些标准库已经存在！所以 Boost 说真的“使用标准”。

【解决方案3】：

根据我自己的经验，我现在更喜欢使用 boost。也许这是历史原因，但我发现 VC2008 附带的 TR1 中的 STD 尝试有太多错误，尽管 PJ Plauger 尽了最大努力，但他无法重现经过同行评审和检查的 boost 代码的质量相当多的历史。

除非他们实际上可以获取 boost 代码并在 STD 中使用它，否则为什么他们会更好地重现它？当然，有时他们可能会，而且真的应该一起努力，而不是互相对抗。

我现在要做的一件事是声明一个别名命名空间，通常称为spns：

namespace spns = boost;

之后，我可以在我的代码中使用spns::shared_ptr（spns 代表“共享指针命名空间”），如果我们稍后更改为 std，则很容易转到一个地方并只编辑该行和包含。

说到 C++11，标准有很大的变化，boost 的代码是 C++03。因此，对于图书馆的某些部分，现在情况可能会发生变化。我认为一些 boost 的优秀库对于 C++11 来说几乎已经过时了，例如没有人会再使用boost::lambda，他们只会对 lambda 使用新的语言语法。

所以是的，当您迁移到 C++11 时，可能是时候放弃部分 boost 库并使用新版本了。

【讨论】：

spns 是共享指针命名空间的缩写吗？您是否为每个功能声明一个命名空间别名？
如果它们不相关，这是有道理的。例如，您可以将一个库用于智能指针，将另一个库用于线程。

【解决方案4】：

我在针对 C++11 开发的开源软件中看到的趋势是将 API 兼容（子集）功能从 STD 转移到 boost——因为 boost 可用于非 C++11 兼容的编译器，其中标准特性（显然）不是。

mosh 就是一个很好的例子。

对于与 API 兼容的功能，只需切换命名空间即可。事实上，如果可以的话，没有理由不将其作为配置选项。

侧边栏：如果您要链接到最新版本的非仅包含标头的 boost 库，请注意某些功能不再可用，除非 boost 是使用 -std=c++11 编译的。我最近在boost::filesystem API 中使用某些函数遇到了这个问题。

【讨论】：

【解决方案5】：

如果某些东西可以成为标准，那就让它成为标准。如果不能，请尽可能使用更标准的解决方案（而 BOOST 就是为此而设计的）

许多标准库功能都取自 boost，它们继续存在以支持在尚未标准化的功能时部署的应用程序。

将 boost 用于标准化功能实际上是一种“向后看”。有时是必要的（可能是标准库特定的实现不包括所有需要的东西......通常会在 Windows 上看到 boost::thread 而不是 std::thread，因为某些编译器尚未移植 std 实现）但我不会把它定为规则。

【讨论】：

咳咳……没有“上帝”来定义什么是标准而不是什么。被接受为标准的东西并不总是被标记为“标准”（无论如何，每个人都声称是标准）。 Boost 很可能被认为比 C++ 标准库更“标准”（即更稳定、最知名、更广泛使用和接受），因此是我的问题。
事实上有一个“神”：C++ 语言有一个规范，定义了“标准库”必须是什么以及包含什么。标准可能不涵盖某些问题域或某些实现不合标准的事实是其他问题。但标准 C++ 来自一个定义明确的 ANSI 委员会。