Guru of the Week 条款22:对象的生存期(第一部分)

类别:编程语言 点击:0 评论:0 推荐:

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