我应该从使用 boost::shared_ptr 切换到 std::shared_ptr 吗？

Question

我想使用-std=c++0x 0x 在 GCC 中启用对 C++0x 的支持。 我不一定需要 GCC 4.5（以及很快 4.6）中当前支持的 C++11 功能，但我想开始习惯它们。 例如，在我使用迭代器的一些地方， auto类型会很有用。

但同样，我不需要任何当前支持的功能。 这里的目标是鼓励我将新标准的特性纳入我的编程“词汇表”。

根据您对 C++11 支持的了解，在 GCC 中启用它是一个好主意，然后通过例如从使用boost::shared_ptr切换到std::shared_ptr来完全接受它，因为两者不混合？

PS：我知道这个很好的问题，它比较了shared_ptr的不同风格，但我要求在标准最终确定之前使用更高级别的建议。 另一种说法是，当像 GCC 这样的编译器说它支持“实验性功能”时，这是否意味着我在编译过程中可能会遇到奇怪的错误，这将是主要的时间消耗和 StackOverflow 上神秘问题的来源？

编辑：我决定从std::shared_ptr切换回来，因为我只是不相信它在 GCC 4.5 中的支持，如this question中的示例所示。

Answer 1

切换到std::shared_ptr有几个原因：

• 您删除了对 Boost 的依赖。
• 调试器。 根据您的编译器和调试器，调试器可能对std::shared_ptr是“智能的”，并直接显示指向 object 的位置，而不是说 boost 的实现。 至少在 Visual Studio 中， std::shared_ptr在调试器中看起来像一个普通的指针，而boost::shared_ptr则暴露了一堆 boost 的内部结构。
• 您的链接问题中定义的其他新功能。
• 您将获得一个几乎可以保证启用移动语义的实现，这可能会节省一些引用计数修改。 （理论上——我自己没有测试过）至少从 2014-07-22 开始， boost::shared_ptr理解移动语义。
• std::shared_ptr在数组类型上正确使用delete [] ，而boost::shared_ptr在这种情况下会导致未定义的行为（您必须使用shared_array或自定义删除器） （实际上我是正确的。看到这个- 专门针对仅unique_ptr ，而不是shared_ptr 。）

一个主要的明显理由不：

• 您将自己限制在 C++11 编译器和标准库实现中。

最后，您实际上不必选择。 （如果您的目标是特定的编译器系列（例如 MSVC 和 GCC），您可以轻松地将其扩展为使用std::tr1::shared_ptr （如果可用）。不幸的是，似乎没有检测 TR1 支持的标准方法)

#if __cplusplus > 199711L
#include <memory>
namespace MyProject
{
    using std::shared_ptr;
}
#else
#include <boost/shared_ptr.hpp>
namespace MyProject
{
    using boost::shared_ptr;
}
#endif

Answer 2

我想这取决于你使用多少升压。 我个人只非常谨慎地使用它（实际上是随机数库，在一个项目中）。 我最近开始在我的其他项目中使用-std=c++0x ，并且我在其中使用了新的 std:: 库功能，例如 shared_ptr。 我喜欢我的项目具有最少的依赖关系，所以我宁愿依赖编译器的标准库实现而不是 boost。

但我不认为这个问题有一个万能的答案。

Answer 3

如果可用，您应该始终尽可能使用std::shared_ptr而不是 boost。 这基本上是因为所有使用shared_ptr的新接口都将使用标准共享 ptr。

Answer 4

在编译器允许的情况下开始养成使用 std::shared_ptr 的习惯可能不是一个坏主意。 由于接口与 boost 的 shared_ptr 相同，因此如果需要，您可以随时切换回来。

Answer 5

除了实现的一致性之外， boost::shared_ptr目前与std::shared_ptr相比至少保留了两个利基优势：

• boost::make_shared_noinit的可用性。 它与 arrays 结合使用特别有用，可以避免零初始化的成本和单独分配的开销。 （FWIW，它也是该标准的拟议补充。）
• Boost.Python 特别使用了boost::shared_ptr对类型擦除自定义删除器的支持，但还没有对std::shared_ptr做同样的事情。

Answer 6

如果您只是在一个很好的平台上构建（进行切换）
（注意：您确实有单元测试来验证向后兼容性，不是吗？）

如果您在多个平台上编译会变得有点尴尬，因为您需要验证 g++ 4.5 上的功能在您使用的所有平台上都可用（即为 MAC/Linux 构建默认的 Mac g++ 编译器仍然是几个版本落后于 Linux 上的默认编译器）。

Answer 7

切换到std::shared_ptr的另一个原因：它支持std::unique_ptr ，即具有构造函数。

boost::shared_ptr没有。

Answer 8

我发现 std::shared_ptr 比 boost::shared_ptr 快。 我做了一个测试，你可以查看代码并查看对比boost、Qt和std共享指针的饼图结果。

https://www.osletek.com...