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

Question

我想在-std=c++0x的GCC中启用对C ++ 0x的支持。我并不一定需要GCC 4.5中的任何currently supported C++11 features（很快就会有4.6），但我想开始习惯它们。例如，在我使用迭代器的一些地方，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。

Answer 1

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

• 删除对Boost的依赖。
• 调试器。根据您的编译器和调试器，调试器可能对std::shared_ptr“智能”并直接显示指向的对象，而不是说，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或自定义删除器）（实际上我已经更正了。请参阅this - 此专业化仅适用于unique_ptr，而非shared_ptr。）

一个主要的明显原因：

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

最后，你真的不必选择。 （如果您的目标是特定的编译器系列（例如MSVC和GCC），您可以轻松地将其扩展为在可用时使用std::tr1::shared_ptr。不幸的是，似乎没有一种标准方法来检测TR1支持）< / p>

#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 :: library功能，例如shared_ptr。我喜欢我的项目具有最少的依赖性，所以我宁愿依赖于编译器的标准库实现而不是boost。

但我不认为这个问题有一个通用的答案。

Answer 3

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

Answer 4

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

Answer 5

如果您只是在一个平台上建造（转换开关）
（注意：你确实有单元测试来验证向后兼容性吗？）

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

Answer 6

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

boost::shared_ptr没有。

Answer 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。

Answer 8

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

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