像 std::vector 这样的容器中的智能指针？
我正在学习智能指针 (std::auto_ptr)，只需阅读此处 和此处 智能指针 (std::auto_ptr）不应放入容器（即std::vector）中，因为即使大多数编译器也不会抱怨，而且它可能看起来是正确的。没有规则说智能指针不会在内部复制（例如通过向量类）并转移其所有权，然后指针将变为 NULL。最终，一切都会搞砸。
事实上，这种情况多久发生一次？
有时我有指针向量，如果将来我决定想要有一个智能指针向量，我的选择是什么？
我了解 C++0x 和 Boost 库，但目前，我更愿意坚持使用 STL 方法。
I am learning about smart pointers (std::auto_ptr) and just read here and here that smart pointers (std::auto_ptr) should not be put in containers (i.e. std::vector) because even most compilers won't complain and it might seem correct. There is no rule that says smart pointers won't be copied internally (by vector class for example) and transfer its ownership, then the pointer will become NULL. In the end, everything will be screwed up.
In reality, how often does this happen?
Sometimes I have vectors of pointers and if in the future I decide I want to have a vector of smart pointers what would my options?
I am aware of C++0x and Boost libraries, but for now, I would prefer to stick to a STL approach.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是的，您确实不能将
std::auto_ptr与标准容器一起使用。std::auto_ptr副本并不等效，并且因为允许标准容器（和算法）随意复制其元素，所以这会把事情搞砸。也就是说，复制std::auto_ptr的操作具有不同于单纯对象复制的含义：它意味着转移所有权 。您的选择是：
Yes, you really can't use
std::auto_ptrwith standard containers.std::auto_ptrcopies aren't equivalent, and because standard containers (and algorithms) are allowed to copy their elements at will this screws things up. That is, the operation of copying astd::auto_ptrhas a meaning other than a mere copy of an object: it means transferring an ownership.Your options are:
您所指的问题涉及 auto_ptr，因为它会移动副本的所有权。 shared_ptr 和 unique_ptr 与容器一起工作得很好。
The problem you are referring to concerns auto_ptr since it moves ownership on copy. shared_ptr and unique_ptr work just fine with containers.
与标准容器模板一起使用的任何类型都必须符合该容器的要求。特别是，该类型必须满足CopyConstructible和Assignable类型的要求。
许多智能指针确实满足这些要求，并且可以与标准容器一起使用，但
std::auto_ptr不是其中之一，因为std::auto_ptr的副本并不等同于它们被创建或分配的来源。尽管标准容器的某些实现在某些情况下可以与 auto_ptr 一起使用，但依赖此类实现细节是危险的。
Any type that you use with a standard container template must conform with the requirements for that container. In particular, the type must satisfy the requirements for CopyConstructible and Assignable types.
Many smart pointers do satisfy these requirements and may be used with standard containers but
std::auto_ptris not one of them because copies ofstd::auto_ptrare not equivalent to the source that they were created or assigned from.Although some implementations of standard container may work with
auto_ptrin some situations it is dangerous to rely on such implementation details.理论上，如果您完全了解 STL 容器的内部实现，并且不做任何可能失去 auto_ptr 所有权的事情，则可以将 std::auto_ptr 与 STL 容器一起使用，但实际上，使用带有原始 ptr 的容器要安全得多。
“实际上，这种情况多久发生一次？” - 本身就是一个非常危险的问题。首先，STL——它不是一个单一的标准实现，有很多。每个容器都可以以不同的方式实现容器，因此，为避免所有“容器中的 auto_ptr”地雷而进行高度调整的代码可能会突然切换到另一种 STL 实现。此外，您的代码维护将非常复杂，对代码的任何看起来正确的更改都可能会破坏您的程序。你如何记住这一点或强迫其他维护者记住这一点？在任何可能发生此类更改的地方放置警告？不可能。
所以，结论：这只是一个坏主意，只会带来头痛
theoretically you can use
std::auto_ptrwith STL containers if you completely understand their internal implementation and don't do anything that can lose auto_ptr ownership, but practically it's much more safe to use containers with raw ptrs."In reality, how often does this happen?" - is very dangerous question by itself. first of all, STL - it's not a single standard implementation, there're many. Each one can implement containers in different ways, so your highly tuned code to avoid all "auto_ptr in containers" mines can burst switching to another STL implementation. Also, your code maintenance will be highly complicated, any correctly looking change to your code can break your program. how can you remember that or force others maintainers to remember? putting warnings in any place where such changes can occur? impossible.
so, conclusion: it's just a bad idea that brings nothing but headache
对于具有 auto ptr 数据成员的类，我总是有一个返回新 auto ptr 的克隆方法。然后，我实现一个赋值方法和调用克隆方法的复制构造函数（而不是 auto ptr 的默认赋值运算符）。这样您就可以安全地在 STL 容器中使用该类。
For classes that have an auto ptr data member, I always have a clone method that returns a new auto ptr. I then implement an assignment method and copy constructor that call the clone method (and never the default assignment operator of auto ptr). This way you can safely use the class in STL containers.