std::auto_ptr 到 std::unique_ptr
随着新标准的到来(以及某些编译器中已经可用的部分),新类型 std::unique_ptr
应该是 std::auto_ptr
的替代品。
它们的用法是否完全重叠(这样我可以在我的代码上进行全局查找/替换(不是我会这样做,但如果我这样做))或者我应该意识到一些在阅读文档时不明显的差异?
另外,如果它是直接替换,为什么要给它一个新名称而不是仅仅改进 std::auto_ptr ?
With the new standard coming (and parts already available in some compilers), the new type std::unique_ptr
is supposed to be a replacement for std::auto_ptr
.
Does their usage exactly overlap (so I can do a global find/replace on my code (not that I would do this, but if I did)) or should I be aware of some differences that are not apparent from reading the documentation?
Also if it is a direct replacement, why give it a new name rather than just improve the std::auto_ptr
?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您无法进行全局查找/替换,因为您可以复制
auto_ptr
(后果已知),但unique_ptr
只能移动。任何看起来像的东西都必须至少变成这样
至于其他差异,
unique_ptr
可以正确处理数组(它会调用delete[]
,而auto_ptr< /code> 将尝试调用
delete
。You cannot do a global find/replace because you can copy an
auto_ptr
(with known consequences), but aunique_ptr
can only be moved. Anything that looks likewill have to become at least like this
As for other differences,
unique_ptr
can handle arrays correctly (it will calldelete[]
, whileauto_ptr
will attempt to calldelete
.std::auto_ptr
和std::unique_ptr
在某些方面不兼容,而在其他方面则替换率下降。因此,没有查找/替换还不够好。但是,在查找/替换解决编译错误后,应该可以修复除奇怪的极端情况之外的所有内容。大多数编译错误都需要添加std::move
。100% 兼容,只要您不将其按值传递给另一个函数。
不是100%兼容,但99%兼容似乎并没有错。
100% 兼容,但有一点需要注意,
unique_ptr
必须通过std::move
调用传递。这很简单,因为如果你不正确,编译器会抱怨。100%兼容。
这一点很棘手。 std::auto_ptr 的复制语义是邪恶的。如果类不允许复制,那么 std::unique_ptr 就是一个替代品。但是,如果您尝试为类提供合理的复制语义,则需要更改 std::auto_ptr 处理代码。这很简单,因为如果你没有得到正确的结果,编译器会抱怨。如果您允许复制具有
std::auto_ptr
成员的类,没有任何特殊代码,那么您将感到羞愧并祝您好运。总之,std::unique_ptr 是一个完整的 std::auto_ptr。它不允许在编译时使用
std::auto_ptr
时经常出现错误的行为。因此,如果您谨慎使用std::auto_ptr
,那么切换到std::unique_ptr
应该很简单。如果您依赖 std::auto_ptr 的奇怪行为,那么无论如何您都需要重构代码。std::auto_ptr
andstd::unique_ptr
are incompatible in someways and a drop in replacement in others. So, no find/replace isn't good enough. However, after a find/replace working through the compile errors should fix everything except weird corner cases. Most of the compile errors will require adding astd::move
.100% compatible, as long as you don't pass it by value to another function.
not 100% compatible but 99% compatible doesn't seem wrong.
100% compatible with one caveat,
unique_ptr
s must be passed through astd::move
call. This one is simple as the compiler will complain if you don't get it right.100% compatible.
This one is tricky.
std::auto_ptr
s copy semantics are evil. If the class disallows copying thenstd::unique_ptr
is a drop in replacement. However, if you tried to give the class reasonable copy semantics, you'll need to change thestd::auto_ptr
handling code. This is simple as the compiler will complain if you don't get it right. If you allowed copying of a class with astd::auto_ptr
member without any special code, then shame on you and good luck.In summary,
std::unique_ptr
is an unbrokenstd::auto_ptr
. It disallows at compile time behaviors that were often errors when using astd::auto_ptr
. So if you usedstd::auto_ptr
with the care it needed, switching tostd::unique_ptr
should be simple. If you relied onstd::auto_ptr
's odd behavior, then you need to refactor your code anyway.Herb Sutter 在 GotW #89:
换句话说,虽然全局搜索和替换可能会暂时“破坏”您的代码,但您无论如何都应该这样做:修复编译错误可能需要一些时间,但从长远来看会为您节省更多麻烦。
Herb Sutter has a nice explanation on GotW #89:
In other words, while a global search-and-replace may "break" your code temporarily, you should do it anyway: It may take some time to fix the compile errors, but will save you a lot more trouble in the long run.
AFAIK,
unique_ptr
不是直接替换。它修复的主要缺陷是所有权的隐性转让。另一方面,
unique_ptr
将具有全新的功能:它们可以存储在容器中。AFAIK,
unique_ptr
is not a direct replacement. The major flaw that it fixes is the implicit transfer of ownership.On the other hand,
unique_ptr
will have completely new capabilities: they can be stored in containers.