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

Should I switch from using boost::shared_ptr to std::shared_ptr?

提问by Alan Turing

I would like to enable support for C++0x in GCC with -std=c++0x. I don't absolutely necessarily need any of the currently supported C++11 featuresin GCC 4.5 (and soon 4.6), but I would like to start getting used to them. For example, in a few places where I use iterators, an autotype would be useful.

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

But again, I don't needany of the currently supported features. The goal here is to encourage me to incorporate the features of the new standard into my programming "vocabulary".

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

From what you know of the C++11 support, is it a good idea to enable it in GCC, and then embrace it by, for example, switching from using boost::shared_ptrto std::shared_ptrexclusively as the two don't mix?

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

PS: I'm aware of this good questionwhich compares the different flavors of shared_ptrbut I'm asking a higher level advice on which to use before the standard is finalized. Another way of putting that is, when a compiler like GCC says it supports an "experimental feature", does that mean I am likely to encounter weird errors during compilation that will be major time sinks and a source of cryptic questions on StackOverflow?

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

Edit: I decided to switch back from std::shared_ptrbecause I just don't trust its support in GCC 4.5 as shown by example in this question.

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

采纳答案by Billy ONeal

There are a couple of reasons to switch over to std::shared_ptr:

切换到 的原因有两个std::shared_ptr：

• You remove a dependency on Boost.
• Debuggers. Depending on your compiler and debugger, the debugger may be "smart" about std::shared_ptrand show the pointed to object directly, where it wouldn't for say, boost's implementation. At least in Visual Studio, std::shared_ptrlooks like a plain pointer in the debugger, while boost::shared_ptrexposes a bunch of boost's innards.
• Other new features defined in your linked question.
• You get an implementation which is almost guaranteed to be move-semantics enabled, which might save a few refcount modifications. (Theoretically -- I've not tested this myself)As of 2014-07-22 at least, boost::shared_ptrunderstands move semantics.
• std::shared_ptrcorrectly uses delete []on array types, while boost::shared_ptrcauses undefined behavior in such cases (you must use shared_arrayor a custom deleter)(Actually I stand corrected. See this-- the specialization for this is for unique_ptronly, not shared_ptr.)

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

And one major glaring reason not to:

不这样做的一个主要原因是：

• You'd be limiting yourself to C++11 compiler and standard library implementations.

• 您将仅限于 C++11 编译器和标准库实现。

Finally, you don't really have to choose. (And if you're targeting a specific compiler series (e.g. MSVC and GCC), you could easily extend this to use std::tr1::shared_ptrwhen available. Unfortunately there doesn't seem to be a standard way to detect TR1 support)

最后，你真的不必选择。（如果您的目标是特定的编译器系列（例如 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

回答by Billy ONeal

I suppose it depends how much you use boost. I personally only use it very sparingly (in fact the random number library, in a single project). I've recently started using -std=c++0xfor my other projects, and I use the new std:: library features like shared_ptr in them. I like my projects to have the minimum of dependencies, so I'd rather be dependent on the compiler's standard library implementation than on boost.

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

But I don't think there is a one-size-fits-all answer to this question.

但我认为这个问题没有一刀切的答案。

回答by Puppy

You should always use std::shared_ptrwherever possible, if it's available, instead of boost. This is basically because all new interfaces which use shared_ptrwill use the Standard shared ptr.

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

回答by Chris Mennie

It's probably not a bad idea to start getting into the habit of using std::shared_ptr when allowed by the compiler. Since the interface is the same as boost's shared_ptr you can always switch back if you needed to.

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

回答by Martin York

If you are just building on the one platform that is fine (make the switch)
(Note: You do have unit tests to validate backward compatibility don't you?)

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

If you compile on multiple platforms is where it becomes a little more awkward as you need to validate that the features on g++ 4.5 are available on all the platforms you use (ie building for MAC/Linux the default Mac g++ compiler is still a couple of version's behind the default compilers on Linux).

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

回答by papafi

Another reason to switch over to std::shared_ptr: it supports std::unique_ptr, i.e. has constructor.

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

boost::shared_ptrdoesn't.

boost::shared_ptr没有。

回答by dhaffey

Aside from implementation consistency, boost::shared_ptrcurrently retains at least two niche advantages over std::shared_ptr:

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

• The availability of boost::make_shared_noinit. It's particularly useful in conjunction with arrays, avoiding both the cost of zero-initialization and the overhead of separate allocation. (FWIW, it's also a proposed additionto the standard.)
• Boost.Python makes special use of boost::shared_ptr's support for type-erased custom deleters, but doesn't yet do the same for std::shared_ptr.

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

回答by rosewater

I found std::shared_ptr to be faster than boost::shared_ptr. I did a test, you can review the code and see the pie chart results comparing boost, Qt, and std shared pointers.

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

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

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