Efficitive STL 中有关auto_ptr的一些说明----原则8---永不建立auto_ptr的容器
唉，很多程序员使用STL平台不会拒绝COAPs。更糟的是，很多程序员妄想地把COAPs看作简单、直接、高效地解决经常伴随指针容器（参见条款7和33）资源泄漏的方案。结果，很多程序员被引诱去使用COAPs，即使建立它们不应该成功。
我会马上解释COAPs的幽灵有多令人担心，以至于标准化委员会采取特殊措施来保证它们不合法。现在，我要专注于一个不需要auto_ptr甚至容器知识的缺点：COAPs不可移植。它们能是怎么样的？C++标准禁止他们，比较好的STL平台已经实现了。可以有足够理由推断随着时间的推移，目前不能实现标准的这个方面的STL平台将变得更适应，并且当那发生时，使用COAPs的代码将更比现在更不可移植。如果你重视移植性（并且你应该是），你将仅仅因为它们的移植测试失败而拒绝COAPs。
但可能你没有移植性思想。如果是这样，请允许我提醒你拷贝auto_ptr的独特——有的人说是奇异——的定义。
当你拷贝一个auto_ptr时，auto_ptr所指向对象的所有权被转移到拷贝的auto_ptr，而被拷贝的auto_ptr被设为NULL。你正确地说一遍：拷贝一个auto_ptr将改变它的值：
auto_ptr<Widget> pw1(new Widget); // pw1指向一个Widget auto_ptr<Widget> pw2(pw1); // pw2指向pw1的Widget; // pw1被设为NULL。（Widget的 // 所有权从pw1转移到pw2。） pw1 = pw2; // pw1现在再次指向Widget； // pw2被设为NULL
这非常不寻常，也许它很有趣，但你（作为STL的用户）关心的原因是它导致一些非常令人惊讶的行为。例如，考虑这段看起来很正确的代码，它建立一个auto_ptr<Widget>的vector，然后使用一个比较指向的Widget的值的函数对它进行排序。
bool widgetAPCompare(const auto_ptr<Widget>& lhs,
const auto_ptr<Widget>& rhs) {
return *lhs < *rhs; // 对于这个例子，假设Widget
} // 存在operator<
vector<auto_ptr<Widget> > widgets; // 建立一个vector，然后
// 用Widget的auto_ptr填充它；
// 记住这将不能编译！
sort(widgets.begin(), widgets.end(), // 排序这个vector
widgetAPCompare);
这里的所有东西看起来都很合理，而且从概念上看所有东西也都很合理，但结果却完全不合理。例如，在排序过程中widgets中的一个或多个auto_ptr可能已经被设为NULL。排序这个vector的行为可能已经改变了它的内容！值得去了解这是怎么发生的。
它会这样是因为实现sort的方法——一个常见的方法，正如它呈现的——是使用了快速排序算法的某种变体。我们不关心快速排序的妙处，但排序一个容器的基本思想是，选择容器的某个元素作为“主元”，然后对大于和小于或等于主元的值进行递归排序。在sort内部，这样的方法多多少少看起来像这样：
template<class RandomAccessIterator, // 这个sort的声明
class Compare> // 直接来自于标准
void sort(RandomAccessIterator first,
RandomAccessIterator last,
Compare comp)
{
// 这个typedef在下面解释
typedef typename iterator_traits<RandomAccessIterator>::value_type
ElementType;
RandomAccessIterator i;
... // 让i指向主元
ElementType pivotValue(*); // 把主元拷贝到一个
// 局部临时变量中；参见
// 下面的讨论
... // 做剩下的排序工作
}
除非你是在阅读STL源代码方面很有经验，否则这看起来可能有些麻烦，但其实并不坏。唯一的难点是引用了iterator_traits<RandomAccessIterator>::value_type，而只不过是传给sort的迭代器所指向的对象类型的怪异的STL方式。（当我们涉及iterator_traits<RandomAccessIterator>::value_type时，我们必须在它前面写上typename，因为它是一个依赖于模板参数类型的名字，在这里是RandomAccessIterator。更多关于typename用法的信息，翻到第7页。）
上面代码中棘手的是这一行，
ElementType pivotValue(*i);
因为它把一个元素从保存的区间拷贝到局部临时对象中。在我们的例子里，这个元素是一个auto_ptr<Widget>，所以这个拷贝操作默默地把被拷贝的auto_ptr——vector中的那个——设为NULL。另外，当pivotValue出了生存期，它会自动删除指向的Widget。这时sort调用返回了，vector的内容已经改变了，而且至少一个Widget已经被删除了。也可能有几个vector元素已经被设为NULL，而且几个widget已经被删除，因为快速排序是一种递归算法，递归的每一层都会拷贝一个主元。
这落入了一个很讨厌的陷阱，这也是为什么标准委员会那么努力地确保你不会掉进去。通过永不建立auto_ptr的容器来尊重它对你的利益的工作，即使你的STL平台允许那么做。