为什么 auto_ptr 被弃用?
我听说 auto_ptr
在 C++11 中已被弃用。这是什么原因呢?
我还想知道 auto_ptr
和 shared_ptr
之间的区别。
I heard auto_ptr
is being deprecated in C++11. What is the reason for this?
Also I would like to know the difference between auto_ptr
and shared_ptr
.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
直接替换
auto_ptr
(或最接近的东西无论如何)是unique_ptr
。就“问题”而言,它非常简单:auto_ptr
在分配时转移所有权。unique_ptr
也转移所有权,但由于移动语义的编纂和右值引用的魔力,它可以更自然地做到这一点。它还与标准库的其余部分“契合”得更好(不过,公平地说,其中一些要归功于库的其余部分进行了更改以适应移动语义,而不是总是需要复制)。名称的更改(IMO)也是受欢迎的 -
auto_ptr
并没有真正告诉您太多关于它试图自动化的内容,而unique_ptr
是一个相当合理的(如果简洁的话)所提供内容的描述。The direct replacement for
auto_ptr
(or the closest thing to one anyway) isunique_ptr
. As far as the "problem" goes, it's pretty simple:auto_ptr
transfers ownership when it's assigned.unique_ptr
also transfers ownership, but thanks to codification of move semantics and the magic of rvalue references, it can do so considerably more naturally. It also "fits" with the rest of the standard library considerably better (though, in fairness, some of that is thanks to the rest of the library changing to accommodate move semantics instead of always requiring copying).The change in name is also (IMO) a welcome one --
auto_ptr
doesn't really tell you much about what it attempts to automate, whereasunique_ptr
is a fairly reasonable (if terse) description of what's provided.我发现现有的答案很好,但来自指针的观点。 IMO,理想的答案应该有用户/程序员的视角答案。
首先,(正如 Jerry Coffin 在他的回答中指出的)
shared_ptr : 如果您担心释放资源/内存并且如果您有多个资源/内存可以在不同时间使用该对象的函数,然后使用shared_ptr。
通过不同的时间,考虑一下 object-ptr 存储在多个数据结构中并稍后访问的情况。多线程当然是另一个例子。
unique_ptr :如果您只关心释放内存,并且对对象的访问是顺序的,那么请使用 unique_ptr。
我所说的顺序,是指在任何时候都可以从一个上下文访问对象。例如,创建者创建并在创建后立即使用的对象。创建后,对象存储在FIRST数据结构中。然后,该对象要么在第一个数据结构之后被销毁,要么被移动到第二数据结构。
从这一行开始,我将把共享/唯一 _ptr 称为智能指针。 (auto_ptr也是智能指针,但由于它的设计缺陷,它们已被弃用,我想我会在下一行中指出,它们不应该与智能指针分组。)
从链接: http://www.cplusplus.com/reference/memory/unique_ptr /operator=/
unqiue_ptr 支持的赋值类型
来自 : http://www.cplusplus.com/reference/memory/auto_ptr/operator=/
auto_ptr 支持的分配类型
现在来谈谈为什么复制分配本身如此不受欢迎的原因,我有这样的理论:
这种意外的行为确实令人讨厌,因此也不喜欢 auto_ptr。
(对于有意想要转让所有权的 3.1415926536% 程序员来说,C++11 为他们提供了 std::move(),这使得所有将要阅读和维护代码的实习生的意图一目了然。)
I found the existing answers great, but from the PoV of the pointers. IMO, an ideal answer should have the user/programmer's perspective answer.
First thing first (as pointed by Jerry Coffin in his answer)
shared_ptr : If you are concerned about freeing of resource/memory AND if you have more than one function that could be using the object AT-DIFFERENT times, then go with shared_ptr.
By DIFFERENT-Times, think of a situation where the object-ptr is stored in multiple data-structure and later accessed. Multiple threads, of course is another example.
unique_ptr : If all you are concerned is freeing memory, and the access to object is SEQUENTIAL, then go for unique_ptr.
By SEQUENTIAL, I mean, at any point object will be accessed from one context. E.g. a object that was created, and used immediately after creation by the creator. After creation the object is stored in FIRST data-structure. Then either the object is destroyed after the ONE data-structure or is moved to SECOND data-structure.
From this line, I will refer shared/unique _ptr as smart-pointers. (auto_ptr is also smart-pointer BUT because of flaws in it's design,for which they are being deprecated, and which I think I will point out in next lines, they should not be grouped with smart-pointer. )
From the link : http://www.cplusplus.com/reference/memory/unique_ptr/operator=/
Kind of assignments supported by unqiue_ptr
From : http://www.cplusplus.com/reference/memory/auto_ptr/operator=/
Kind of assignments supported by auto_ptr
Now coming to the reason WHY the copy assignment itself was so disliked, I have this theory :
The unintended behavior is really disliked and hence the dislike for the auto_ptr.
(For the 3.1415926536% of programmers who intentionally wants to transfer the ownership C++11 gave them std::move(), which made their intention crystal clear for all the interns who are going to read and maintain the code.)
shared_ptr
可以存储在容器内。auto_ptr
不能。顺便说一句,
unique_ptr
实际上是auto_ptr
的直接替代品,它结合了std::auto_ptr
和boost::scoped_ptr<的最佳功能。 /代码>。
shared_ptr
can be stored inside containers.auto_ptr
can't.BTW
unique_ptr
is really the directauto_ptr
replacement, it combines the best features of bothstd::auto_ptr
andboost::scoped_ptr
.解释差异的另一种方式......
从功能上讲,C++11 的
std::unique_ptr
是“固定”std::auto_ptr
:它们都适合当 - 在执行期间的任何时间点 - 所指向的对象应该有一个智能指针所有者。关键的区别在于来自另一个未过期智能指针的复制构造或赋值,如下面的
=>
行所示:上面是
ap3
auto_ptr
悄悄“窃取”*ap
的所有权,将ap
设置为nullptr
,问题就来了是这种情况很容易发生,而程序员却没有考虑到它的安全性。例如,如果
class
/struct
有一个std::auto_ptr
成员,则创建实例的副本将release< /code> 正在复制的实例的指针:这是奇怪且危险的令人困惑的语义,因为通常复制某些内容不会修改它。类/结构作者在推理不变量和状态时很容易忽略指针的释放,因此意外地尝试在 null 时取消引用智能指针,或者只是仍然不具有所指向数据的预期访问/所有权。
Yet another take on explaining the difference....
Functionally, C++11's
std::unique_ptr
is the "fixed"std::auto_ptr
: both of them are suitable when - at any point in time during execution - there should be a single smart-pointer owner for a pointed-to object.The crucial difference is in copy-construction or assignment from another un-expiring smart pointer, shown on the
=>
lines below:Above, the
ap3
auto_ptr
quietly "steals" ownership of*ap
, leavingap
set to anullptr
, and the problem is that can happen too easily, without the programmer having thought through its safety.For example, if a
class
/struct
has astd::auto_ptr
member, then making a copy of an instance willrelease
the pointer from the instance being copied: that's weird and dangerously confusing semantics as usually copying something doesn't modify it. It's easy for the class/struct author to overlook the release of the pointer when reasoning about invariants and state, and consequently accidentally attempt to dereference smart-pointer while null, or just not still have expected access/ownership of the pointed-to data.auto_ptr 不能在 STL 容器中使用,因为它的复制构造函数不满足容器的要求 可复制构造。 unique_ptr 不实现复制构造函数,因此容器使用替代方法。 unique_ptr可以在容器中使用,对于std算法来说比shared_ptr更快。
auto_ptr cannot be used in STL containers because it has a copy constructor that does not meet requirements of container CopyConstructible. unique_ptr does not implement a copy constructor, so containers use alternate methods. unique_ptr can be used in containers and is faster for std algorithms than shared_ptr.