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

Question

我想在GCC中启用对C++ 0x的支持-std=c++0x.我并不一定需要GCC 4.5中的任何当前支持的C++ 11功能(很快就会有4.6),但我想开始习惯它们.例如,在我使用迭代器的一些地方,auto类型会很有用.

但同样,我不需要任何当前支持的功能.这里的目标是鼓励我将新标准的特征融入我的编程"词汇"中.

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

PS:我知道这个比较不同口味的好问题,shared_ptr但是我要求在标准最终确定之前提出更高级别的建议.另一种说法是,当像GCC这样的编译器说它支持"实验性功能"时,这是否意味着我可能会在编译过程中遇到奇怪的错误,这些错误将成为主要的时间汇,并且是StackOverflow上一个神秘问题的来源？

编辑:我决定退回,std::shared_ptr因为我只是不相信它在GCC 4.5中的支持,如本问题中的示例所示.

Answer 1

有几个原因可以切换到std::shared_ptr:

• 您删除了对Boost的依赖.
• 调试器.根据您的编译器和调试器,调试器可以"智能" std::shared_ptr并直接显示指向对象,而不是说,boost的实现.至少在Visual Studio中,std::shared_ptr看起来像调试器中的普通指针,同时boost::shared_ptr暴露了一堆boost的内部.
• 您链接的问题中定义的其他新功能.
• 您将获得一个几乎可以保证启用了移动语义的实现,这可能会节省一些refcount修改.(从理论上讲 - 我自己没有对此进行测试)至少从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 :: library功能,例如shared_ptr.我喜欢我的项目具有最少的依赖性,所以我宁愿依赖于编译器的标准库实现而不是boost.

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

Answer 3

你应该std::shared_ptr尽可能地使用,如果它可用,而不是提升.这基本上是因为所有使用的新接口都shared_ptr将使用Standard shared ptr.

Answer 4

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