对话#25：Getting to the Point（WQ译）
“啊！”
这一个小时内我第七次受挫后的大叫。 温迪明显不胜其扰了。”瞧瞧，朋友，安静一下，好吧？”她的声音飘过隔间。我觉得她的反应比以前好多了。
我以前就和auto_ptrs搏斗过了。在为Guru干活的最初几天内，我已经领教过auto_ptrs的价值了－以及它那不显眼的陷阱[1]. 我已经被auto_ptr那奇怪的所有权问题扎过一次了。auto_ptr使用伪装为拷贝操作的移交操作。想像一下这种情况: 你在操作一个复印机，放上你的表格，然后按 “拷贝”按钮。过了一会儿，复印机给你副本－然后将原件送入碎纸器。这就是auto_ptr的拷贝和赋值操作干的好事。
无论如何，我现在已经更聪明和更富有经验了，可仍然正陷入在auto_ptr的形形色色的限制之中。比如说，auto_ptr不能用来包容指向数组的指针。我玩弄了一个Hacking的技巧来绕开它，通过使用显式的数组delete：
auto_ptr<T> autoArray(new T[10]);
//...
delete [] autoArray.release;()
但立刻就后悔了。我可以预见到这个 “面目可憎的东西”(Guru会也会这么称呼它) 的许多危险。最重要的是，嗯，auto_ptr的卖点就是拥有和销毁内存；手工这么做完全打破了使用它的本意。
因此,我决定改用一个vector来拥有数组。它比我所需要的还更强劲一些，因为我不需要动态更改vector的大小，而它提供了此功能。 我实际上想要是一个能自动处理指针和内存管理的灵巧指针，并且可以用来处理数组。
“使用Boost库, 天行者，”我听到身后Guru的声音。
“是不是‘使用大场，天行者’？” 我侧肩答道。 “而且，不要叫我天行者。”
“Boost是能量的源泉，”Guru继续于她的电影台词之中。
我今天没心情，于是我打断了她。”嗯，我们能今天不用演戏吗？鲍伯在伦敦的办公室里，也没有新员神情反常。”
她来到附近，我看见了她的微笑和耸肩。”哦，我仅仅感到无聊，”她叹了口气。”你看过Boost库中的灵巧指针了吗？”
“嗯，”我吞吞吐吐的，”我还没空仔细去看Boost库。它怎么实现灵巧指针的？”
“共有五种灵巧指针，”Guru一边坐下一边说着。”两个处理指针的单所有权，两个处理共享所有权。”
“共享所有权？哦，类似于带引用计数的类？”
“完全正确。灵巧指针是成对的，一个处理指向单一物体的指针，另一个处理指向数组的指针。”在说的时候，她在白板上写下：scoped_ptr，scoped_array，shared_ptr和 shared_array。
“只有四个，你前面说有五个？”我问。
“剩下的一个叫weak_ptr。它是shared_ptr的非拥有关系的观察者。我随后讲它。 scoped_*形灵巧指针在它们离开生存范围时，自动析构所指向的对象。一个提议用途是实现Pimpl惯用法－指向实现的指针，”在我发问前，她急忙加了一句。
“如此说来...他们象auto_ptr，对吧？”
“不十分象。scoped_ptr和scoped_array不可拷贝。”
“不可拷贝？那么，如果我将一个指针作为类的成员－”我边说边在白板上潦草地写着：
class T
{
scoped_ptr<TImpl> p;
...
“－我如何实现拷贝和赋值？”
“和auto_ptr一样，”Guru边答边写：
T( const T& other )
: p(new TImpl(*other.p)
{
}
T& operator=( const T& other )
{
scoped_ptr<TImpl> tmp(new TImpl(*other.p));
p.swap;(tmp)
}
“Ooookay，”我懒洋洋地说着，装作我已经懂了。“ 于是，当我使用scoped_ptr的时候, 我必须同样完成使用auto_ptr时所必须做的所有工作，对吧？那么为什么不就使用auto_ptr？”
“因为使用auto_ptr时能编译，但是做错事, 因为自动生成的函数。 使用 scoped_ptr 使得极难忽略拷贝语义，因为如果你使用编辑器自动生成的版本时，编辑器将会拒绝编译这个类。同样，scoped_ptr不能够在一个不完全的类型上被使用。”我给予了Guru我擅长的车前灯前的鹿的目光。 她叹了口气。“考虑这种情况，”她边说边在白板上写:
class Simple;
Simple * CreateSimple();
void f()
{
auto_ptr<Simple>autoS(CreateSimple());
scoped_ptr<Simple>scopedS(CreateSimple());
//...
}
“在函数体中，Simple是一个不完全的类型。如果它的析构函数是有行为的，那么通过auto_ptr或scoped_ptr销毁它，其结果为未定义。一些编译器在你实例化auto_ptr时将会警告你这一点，但不是所有编译器都会这么做。相对的，scoped_ptr为确保语义正确而做了些小动作以造成编译错误，如果是在实例化一个不完全类型的话。”
“哦，是的，当然，” 我来劲了，以显示我理解了。 “因此我们应该始终使用scoped_ptr来代替auto_ptr，对吧？”
“错，抱歉，” 她失望地说道。“auto_ptr仍然有它的用处。不像auto_ptr，scoped_ptr 没有release()成员－它不能够放弃指针的所有权。 因为这个，以及因为scoped_ptr不能够被复制，当scoped_ptr离开生存范围时，它所管理的指针总是被delete。这使得scoped_ptr不适用于需要传递所有权的地方，比如厂。”
“使用scoped_ptr向其他程序员表明你的意图。它告诉其他人，‘这个指针不应该在当前范围外被复制’。正相反，auto_ptr允许从产生指针的代码空间向外传递所有权，但是它维持对指针的控制除非所有权的传递是完全地。 这当然对写异常安全的代码有重要意义。”
“啊，好，我明白了，”我嘟囔着。“ 你提到的另一种灵巧指针是怎么回事？”
“scoped_array的行为和scoped_ptr相同，除了它处理是对象数组而不是单个对象。 scoped_array 提供了稍有差别的访问函数。它没有operator*或operator->，但它有operator[]。我相信，”她总结道，“你需要是一个 scoped_array。”
“也许吧，”我答道，”但是我认为在作决定之前我应该多了解些shared_*形的灵巧指针。”
“非常明智，我的徒……弟，抱歉，叫习惯了。”Guru歉意地笑了一下。“是的, 熟悉各个选择之后再作决定是个好习惯。”
她指着白板上的shared_ptr 和 shared_array说道：“shared_*形的灵巧指针是非常有用的工具。 他们是引用计数型的指针，能够区分出所有者和观察者。举例来说, 使用上面的class T：”
void sharing()
{
shared_ptr<T> firstShared(new T);
shared_ptr<T> secondShared;(firstShared)
//...
}
“两个shared_ptr对象指向相同的T对象。引用计数现在是2。既然shared_ptr是引用计数的，对象一直不被销毁直到最后一个shared_ptr离开生存范围－此时引用计数降为0。shared_*的灵巧指针有相当的柔性，你可以使用它们包容指向不完全类型的指针。”
“我想你说过的，这很糟吧？”
“是很糟，如果你不小心的话。 shared_*的灵巧指针可以用一个指向不完全类型的指针来实例化，但必须要指明一个函数或函数子供销毁被拥有对象时调用。比如说，我们修改了上面的f函数：”
void DestroySimple( Simple* );
void f()
{
shared_ptr<Simple>sharedSFails( CreateSimple() );
shared_ptr<Simple>sharedSSucceeds( CreateSimple(), DestroySimple );
}
“第一个shared_ptr失败了, 因为Simple是一个不完全类型。第二个成功了，因为你明确地告诉了 shared_ptr 该如何销毁这个指针。
“因为 shared_ 指针被设计可被拷贝，它们完全适用于标准容器, 包括associative 容器。并且，在那些必须强制类型转换的特别场合上，可以定义特别的类型转换操作以生成新的shared_*形的灵巧指针。 例如，如果我们有一个类Base以及公有继承而来的Derived，和一个无关类，那么你将遇到：”
void g()
{
shared_ptr<Base>sharedBase( new Derived );
shared_ptr<Derived> sharedDer =
shared_dynamic_cast<Derived>( sharedBase);
shared_ptr<Unrelated> sharedUnrelated =
shared_dynamic_cast<Unrelated>( sharedBase);
try
{
shared_ptr<Unrelated> oops =
shared_polymorphic_cast<Unrelated>( sharedBase);
}
catch( bad_cast)
{
//...
}
}
“同样还存在着一个shared_static_cast，供那些特别场合使用，”Guru总结道。
我对这个函数研究了一会儿。“好吧，让我试试是否能推算出将发生什么。第一个shared_dynamic_cast在灵巧指针上执行了一个dynamic_cast，返回一个新的灵巧指针。 假如dynamic_cast失败了怎么办－在引用计数上将发生什么？”
Guru满意地点点头。“在那种情况下，原始的计数不被影响，而且新的hared_ptr包容的是一个NULL指针。正如你从try/catch语句推测的，shared_polymorphic_cast将试图在被容纳的指针上执行dynamic_cast。 如果转换失败，它将抛出bad_cast异常。”
“哇，”我赞叹道，“这个类可真完备。看起来很不错。”
“的确，”Guru同意。 “但还有些事情是必须要知道的。引用计算过于简单而不能检测任何形式的循环引用。同样，shared_ptr也没有实现任何形式的写时拷贝（copy-on-write），因此用它来实现Pimpl惯用法时必须仔细衡量。”
我深思熟虑后确定我喜欢它。“嗨，”我追问道，我还记着呢，“你提到过的weak_ptr是怎么回事？”
“啊，是的。weak_ptr与shared_ptrs联合使用。weak_ptr是观察者，不影响共享对象的引用计数。weak_ptr的主要目的是允许shared_ptr参与循环依赖－A引用B，B反过来又引用A。我喜欢将它想象成俱乐部中的准会员－它没有投票权，但是能参加俱乐部的会议。”
“Hmmm……” 我仔细想了一下。“因为 weak_ptr不影响引用计数，如果俱乐部解散了怎么办－也就是说，最後一个shared_ptr离开了生存范围－而此时 weak_ptr正在使用共享对象？”
“在那情况下，weak_ptr维护的指针被设置为NULL。而对于NULL，不能进行任何dereferencing操作，例如operator*、operator->、或operator[]，在dereferencing指针前应该进行NULL检查。于是，正如dereferencing内建指针前必须进行NULL检查，你也一定要检查灵巧指针是否为NULL。这个限制适用于Boost库中的所有灵巧指针。”
“天那，要记太多的东西了，”我一边说一边盯着潦草地写在白板上的东西。
“别担心，”Guru微笑着站起离开了。“我会email给你Boost库的URL，以及练习和示范各种不同指针的一个小程序。”她当然说到做到，几分钟内我收到了她的email。 我读到这句时立即就闭上了眼睛：
“我的徒弟，如前所说，这是Boost库中的说明文档: <www.boost.org/libs/smart_ptr/smart_ptr.htm>[2]。 阅读并思考附上问题[3]。”
[感谢]
Thanks to Peter Dimov and Bjorn Karlsson for providing valuable comments and updates.
[注释]
[1] Jim Hyslop and Herb Sutter. “Conversations #1,” C++ Report, April 2000.
[2] The most recent version of the library and documentation can also be obtained via anonymous CVS checkout from the Source Forge project. Detailed instructions can be found at: <http://sourceforge.net/projects/boost/>.
[3] The sample code can be downloaded from the CUJ website: hyslop.zip.
