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

【问题标题】：Should I switch from using boost::shared_ptr to std::shared_ptr?我应该从使用 boost::shared_ptr 切换到 std::shared_ptr 吗？
【发布时间】：2011-09-13 09:57:37
【问题描述】：

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

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

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

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

编辑：我决定从 std::shared_ptr 切换回来，因为我只是不相信它在 GCC 4.5 中的支持就像 shown by example in this question。

【问题讨论】：

我想知道 boost 在使用支持它的编译器时是否可以只对 std::shared_ptr 使用 typedef？
在这里找不到具体问题？投票结束。
我认为这个问题很清楚，只是答案不是简单的是或否。答案需要一个赞成/反对列表，就像我标记为答案的那个。问题本质上是：您是否建议在标准最终确定之前使用 std::shared_ptr ？为什么或为什么不？

标签： c++ boost stl c++11 shared-ptr

【解决方案1】：

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

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

【讨论】：

typedef shared_ptr std::shared_ptr?
@GManNickG：哈哈。接得好。该死的typedef向后工作！（感觉像是给我的任务）
@GManNickG: 嗯...回头看看这也许使用语句会更好。你怎么看？
是的，模板using 是正确的：template <typename T> using shared_ptr = std::shared_ptr<T>;。问题是这是一个 C++11 特性，所以你不能在 boost::shared_ptr 的情况下使用它。 :) C++03 方式是another type with an internal typedef.
@GMan：你不能只做“使用 std::shared_ptr;”，然后把那个名字带进那个命名空间吗？

【解决方案2】：

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

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

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

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

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

【讨论】：

【解决方案6】：

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

boost::shared_ptr 没有。

【讨论】：

【解决方案7】：

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

boost::make_shared_noinit 的可用性。它与数组结合使用特别有用，可以避免零初始化的成本和单独分配的开销。（FWIW，它也是标准的proposed addition。）
Boost.Python 特别利用了boost::shared_ptr 对类型擦除自定义删除器的支持，但doesn't yet do the same for std::shared_ptr。

【讨论】：

【解决方案8】：

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

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

【讨论】：

我很惊讶地看到 malloc 和 new 的情况如此之快。如果性能损失是慢 10 倍的调用，我认为没有人愿意使用智能指针。您的测试用例不具有可比性：1. malloc 和 new 只被调用一次，分配大小为 LENGTH 的数组，而在所有其他情况下，分配完成 LENGTH 次，2. 对于 malloc 和 new，您将 rand 的结果分配给分配的数组，而在所有其他情况下，分配的结果被推回向量中，导致进一步的内存分配/重新分配。
附带说明：饼图不是显示此类数据的非常有用的方式。这篇文章告诉你为什么...perceptualedge.com/articles/visual_business_intelligence/…