std :: auto_ptr到std :: unique_ptr
随着新的标准的到来（和一些编译器已经可用的部分），新的std::unique_ptrtypes应该是std::auto_ptr的替代品。
他们的使用是否完全重叠（所以我可以在我的代码上进行全局查找/replace（不是我会这样做，但是如果我这样做）），还是应该知道读取文档中不明显的一些差异？
另外，如果它是一个直接replace（为什么给它一个新的名字），而不是改善std::auto_ptr 。
您不能执行全局查找/replace，因为您可以复制auto_ptr （具有已知的结果），但unique_ptr只能移动。 任何看起来像
std::auto_ptr<int> p(new int); std::auto_ptr<int> p2 = p;
将不得不至less变成这样
std::unique_ptr<int> p(new int); std::unique_ptr<int> p2 = std::move(p);
至于其他差异， unique_ptr可以正确处理数组（它将调用delete[] ，而auto_ptr将尝试调用delete 。
std::auto_ptr和std::unique_ptr在某些方面是不兼容的，而在另外一些方面则是替代方式的一个缺陷。 所以，没有find/replace是不够的。 但是，通过编译错误的查找/replace工作之后，应该修复除了奇怪的angular落案件之外的所有事情。 大部分的编译错误都需要添加一个std::move 。
- 函数范围variables：
100％兼容，只要你不把它通过价值传递给另一个function。 - 返回types：
不是100％兼容，但99％兼容似乎没有错。 - 函数参数值：
100％兼容一个警告，unique_ptr必须通过一个std::move调用。 这一个很简单，因为编译器会抱怨，如果你不正确的话。 - function参数参考：
100％兼容。 - 类成员variables：
这一个是棘手的。std::auto_ptr的复制语义是邪恶的。 如果这个类不允许复制，那么std::unique_ptr就是一个replace。 但是，如果您试图给该类合理的复制语义，您将需要更改std::auto_ptr处理代码。 这很简单，因为编译器会抱怨，如果你不正确的话。 如果你允许一个std::auto_ptr成员的类没有任何特殊的代码复制，然后羞辱你，祝你好运。
总之， std::unique_ptr是一个完整的std::auto_ptr 。 它在编译时不允许使用std::auto_ptr时经常出错的行为。 所以，如果你在使用std::auto_ptr时需要小心，切换到std::unique_ptr应该很简单。 如果你依赖于std::auto_ptr的奇怪行为，那么你仍然需要重构你的代码。
AFAIK， unique_ptr不是直接replace。 它修正的主要缺陷是所有权的隐含转移。
std::auto_ptr<int> a(new int(10)), b; b = a; //implicitly transfers ownership std::unique_ptr<int> a(new int(10)), b; b = std::move(a); //ownership must be transferred explicitly
另一方面， unique_ptr将具有全新的function：它们可以存储在容器中。
草药萨特在GotW＃89上有一个很好的解释：
与auto_ptr有什么关系？ 在C ++移动语义之前，auto_ptr最具有慈善特征，就是勇于创buildunique_ptr。 auto_ptr现在已被弃用，不应在新代码中使用。
如果你有一个现有的代码库中的auto_ptr，当你有机会尝试做一个全局的search和replaceauto_ptr unique_ptr; 绝大多数的用法都是一样的，它可能会暴露（作为编译时错误）或修复（默默地）一个你不知道的错误。
换句话说，尽pipe全局的search和replace可能会暂时“破坏”你的代码，但你仍然应该这么做：修正编译错误可能需要一些时间，但是从长远来看将会为你节省更多的麻烦。
