std::auto_ptr 到 std::unique_ptr

发布于 2024-09-13 17:20:01 字数 239 浏览 10 评论 0原文

随着新标准的到来(以及某些编译器中已经可用的部分),新类型 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

天冷不及心凉 2024-09-20 17:20:01

您无法进行全局查找/替换,因为您可以复制 auto_ptr (后果已知),但 unique_ptr 只能移动。任何看起来像的东西都

std::auto_ptr<int> p(new int);
std::auto_ptr<int> p2 = p; 

必须至少变成这样

std::unique_ptr<int> p(new int);
std::unique_ptr<int> p2 = std::move(p);

至于其他差异,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 a unique_ptr can only be moved. Anything that looks like

std::auto_ptr<int> p(new int);
std::auto_ptr<int> p2 = p; 

will have to become at least like this

std::unique_ptr<int> p(new int);
std::unique_ptr<int> p2 = std::move(p);

As for other differences, unique_ptr can handle arrays correctly (it will call delete[], while auto_ptr will attempt to call delete.

魂ガ小子 2024-09-20 17:20:01

std::auto_ptrstd::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 and std::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 a std::move.

  • Function scope variable:
    100% compatible, as long as you don't pass it by value to another function.
  • Return type:
    not 100% compatible but 99% compatible doesn't seem wrong.
  • Function parameter by value:
    100% compatible with one caveat, unique_ptrs must be passed through a std::move call. This one is simple as the compiler will complain if you don't get it right.
  • Function parameter by reference:
    100% compatible.
  • Class member variable:
    This one is tricky. std::auto_ptrs copy semantics are evil. If the class disallows copying then std::unique_ptr is a drop in replacement. However, if you tried to give the class reasonable copy semantics, you'll need to change the std::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 a std::auto_ptr member without any special code, then shame on you and good luck.

In summary, std::unique_ptr is an unbroken std::auto_ptr. It disallows at compile time behaviors that were often errors when using a std::auto_ptr. So if you used std::auto_ptr with the care it needed, switching to std::unique_ptr should be simple. If you relied on std::auto_ptr's odd behavior, then you need to refactor your code anyway.

椵侞 2024-09-20 17:20:01

Herb Sutter 在 GotW #89

auto_ptr 是怎么回事? auto_ptr 被最仁慈地描述为在 C++ 之前创建 unique_ptr 的勇敢尝试
具有移动语义。 auto_ptr 现已弃用,不应使用
在新代码中。

如果现有代码库中有 auto_ptr,当您有机会时
尝试进行全局搜索并将 auto_ptr 替换为 unique_ptr;这
绝大多数用途都会以相同的方式工作,并且它可能会暴露(作为
编译时错误)或修复(默默地)一两个你不知道的错误
曾经。

换句话说,虽然全局搜索和替换可能会暂时“破坏”您的代码,但您无论如何都应该这样做:修复编译错误可能需要一些时间,但从长远来看会为您节省更多麻烦。

Herb Sutter has a nice explanation on GotW #89:

What’s the deal with auto_ptr? auto_ptr is most charitably characterized as a valiant attempt to create a unique_ptr before C++
had move semantics. auto_ptr is now deprecated, and should not be used
in new code.

If you have auto_ptr in an existing code base, when you get a chance
try doing a global search-and-replace of auto_ptr to unique_ptr; the
vast majority of uses will work the same, and it might expose (as a
compile-time error) or fix (silently) a bug or two you didn't know you
had.

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.

情泪▽动烟 2024-09-20 17:20:01

AFAIK,unique_ptr 不是直接替换。它修复的主要缺陷是所有权的隐性转让。

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 将具有全新的功能:它们可以存储在容器中。

AFAIK, unique_ptr is not a direct replacement. The major flaw that it fixes is the implicit transfer of ownership.

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

On the other hand, unique_ptr will have completely new capabilities: they can be stored in containers.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文