In short, even though a compiler wouldn't burp a single warning here, auto_ptrs are NOT safe to put in containers. This is because we have no way of warning the container that copying auto_ptrs has unusual semantics (transferring ownership, changing the right-hand side's state). True, today most implementations I know about will let you get away with this, and code nearly identical to this even appears as a "good example" in the documentation of certain popular compilers. Nevertheless, it was actually unsafe (and is now illegal).
简而言之,尽管编译器不会对此给出任何警告,把auto_ptr放入container仍是不安全的。这是因为我们无法告知这个container关于「auto_ptr具有特殊的语义(传递所有权,改变右手边的状态)」的情况。不错,如今我所知的大多数auto_ptr实现都会让你侥幸摆脱这个麻烦;而且在某些流行的编译器所提供的文档中,与此几乎相同的代码甚至还被作为“优良的代码”而给出。然而实际上它是不安全的(现在成为非法的了)。
The problem is that auto_ptr does not quite meet the requirements of a type you can put into containers, for copies of auto_ptrs are not equivalent. For one thing, there's nothing that says a vector can't just decide to up and make an "extra" internal copy of some object it contains. Sure, normally you can expect vector not to do this (simply because making extra copies happens to be unnecessary and inefficient, and for competitive reasons a vendor is unlikely to ship a library that's needlessly inefficient), but it's not guaranteed and so you can't rely on it.
其问题在于,auto_ptr并不满足对能够放入container的型别之需求,因为auto_ptr之间的拷贝是不等价的。首先有一点,并没有谁规定一个vector不能为其包含的对象创建一份“额外”的拷贝放在内部。当然,在正常情况下你可以认为vector不会这样做(因为创建额外的拷贝实在是不必要和低效的;出于商业竞争的考虑,一个厂商当然不大可能会发售一个本来可以很高效的低效程序库),但这并无任何保证,因而你也就不能依赖于这个假设。