GotW #22 Object Lifetimes – Part I
著者：Herb Sutter
翻译：K ][ N G of @rk™
[声明]：本文内容取自www.gotw.ca网站上的Guru of the Week栏目，其著作权归原著者本人所有。译者kingofark在未经原著者本人同意的情况下翻译本文。本翻译内容仅供自学和参考用，请所有阅读过本文的人不要擅自转载、传播本翻译内容；下载本翻译内容的人请在阅读浏览后，立即删除其备份。译者kingofark对违反上述两条原则的人不负任何责任。特此声明。
Revision 1.0
Guru of the Week 条款22：对象的生存期（第一部分）
难度：5 / 10
（“生存，还是灭亡……[译注：这是莎士比亚所著《哈姆雷特》中的名句]” 一个对象何时才算是真实存在的？这个问题用来考察一个对象何时才能被安全的使用。）
[Problem]
[问题]
评述下面的程序段。#2处的代码使安全和/或合法的吗？请对你的回答做出解释。
void f() {
T t(1);
T& rt = t;
// #1: 使用t或者rt做一些事情
t.~T();
new (&t) T(2);
// #2: 使用t或者rt做一些事情
} // t被再次销毁
[解答]
是的，#2处的代码是安全且合法的（如果只考虑这部分代码的话），但：
a) 函数作为一个整体，它是不安全的，而且
b) 这样做是一个坏习惯。
[为什么#2是安全的（如果只考虑这部分代码的话）？]
C++标准草案明确规定，允许这种代码出现。现场的析构和重构造（in-place destruction and reconstruction）不会使rt这个引用失效。（当然，你不能在t.~T()与placement new之间使用t或rt，因为在那段时期里不存在任何对象。我们还假设T::operator&()没有被重载，即没有被用来做「返回对象之地址」以外的其它事情。）
我们之所以说“如果只考虑这部分代码的话，#2就是安全的”，是因为f()作为一个整体而言，可能不是异常安全的（exception-safe）：
[为什么函数是不安全的？]
如果在调用T(2)的时候，T的构造函数有抛出异常的可能，那么f()就不是异常安全的。考虑其原因：如果T(2)抛出异常，那么在原来’t’所在的内存区域中将不会有新的对象被构造，而在函数末尾T::~T()仍然被正常调用（因为t是一个自动变量[automatic variable]），而且正如代码中的注释所述，“t被再次销毁”。这即是说，’t’会被构造一次，却被销毁两次（呜呼呀）。这将导致容易产生无法预见的副作用，比如core dumps。
[为什么这是个坏习惯？]
如果忽略异常安全性的问题，那么代码在这样的设定下恰好就能够正常工作，这是因为程序员此时知道被构造和销毁之对象的具体型别。这即是说，该对象是一个T，并被作为一个T来被销毁和重新构造。
在实际的代码中，这种技术（即便真是编码所需）几乎不会被使用，并且这样做也是非常坏的习惯；原因是：如果其出现在成员函数中，那么其将会充满（有时难以捉摸的）危险：
void T::f( int i ) {
this->~T();
new (this) T(i);
}
现在这种技术还算安全吗？基本上来说，不安全。考虑下面的代码：
class U : /*...*/ public T { /* ... */ };
void f() {
/*AAA*/ t(1);
/*BBB*/& rt = t;
// #1: 使用t或者rt做一些事情
t.f(2);
// #2: 使用t或者rt做一些事情
} // t被再次销毁
如果”/*AAA*/”是”T”，那么#2处的代码仍然可行，即使”/*BBB*/”不是”T”（ ”/*BBB*/”可能是T的基类）。
如果”/*AAA*/”是”U”（译注：而不是”T”），那么无论”/*BBB*/”是什么，都已经毫无悬念了。大概你所能期待的最好结果就是一个及时的core dump，因为对t.f()的调用将对象“切割（slices）”了。这里说的“切割”是指：t.f()用属于另一个不同型别的对象替换了原来的对象——这即是说函数使用了T而不是U。即便是你意欲编写不可移植的代码，你也无法知晓「当原来U所在的内存区域被T对象之数据抹盖以后，其被作为U是否还可用？」。固然还是有情况尚佳的机率，但是请不要走到那个地步……这绝不是一次良好的实践。
本期GotW包含了一些基本的、有关现场析构和重构（in-place destruction and reconstruction）的安全性问题和切割问题。这为下期的“GotW条款23：对象生存期（第二部分）”作下铺垫。
（完）
本文地址：http://com.8s8s.com/it/it29783.htm