Guru of the Week 条款02: 临时对象

GotW #02 Temporary Objects

著者：Herb Sutter     

翻译：kingofark

[声明]：本文内容取自www.gotw.ca网站上的Guru of the Week栏目，其著作权归原著者本人所有。译者kingofark在未经原著者本人同意的情况下翻译本文。本翻译内容仅供自学和参考用，请所有阅读过本文的人不要擅自转载、传播本翻译内容；下载本翻译内容的人请在阅读浏览后，立即删除其备份。译者kingofark对违反上述两条原则的人不负任何责任。特此声明。

Revision 1.0

Guru of the Week 条款02: 临时对象

难度：5 / 10

（把你的心血之作（包括你的程序之性能在内）当成垃圾抛出窗外的罪人，往往是一些意想不到的临时对象。）

 

 

[问题]

 

试想你正在阅读另一个程序员写好的函数代码（如下），而这个函数中却在至少三个地方用到了不必要的临时对象。那么，你能发现其中的几个呢？程序员又该如何修改代码呢？

 

  string FindAddr( list<Employee> l, string name )
  
  

  {
  
  

    for( list<Employee>::iterator i = l.begin();
  
  

         i != l.end();
  
  

         i++ )
  
  

    {
  
  

      if( *i == name )
  
  

      {
  
  

        return (*i).addr;
  
  

      }
  
  

    }
  
  

    return "";
  
  

  }
  
  

 

 

[解答]

 

信不信由你，这短短的几行代码中就起码有三个地方明显的使用了不必要的临时对象，其中有两个比较微妙，第三个则是一计遮眼法（red herring）。

 

 

*        string FindAddr( list<Employee> l, string name )
  
  

---- 第1处 ----     ---- 第2处 ----

 

1和2：两个参数都应该使用常量引用（const reference）。使用传值（pass-by-value）方式将会导致函数对list和string进行拷贝，其性能代价是高昂的。

 

[规则]：请使用const&而不是传值拷贝。

 

 

*         for( list<Employee>::iterator i = l.begin();
  
  

                  i != l.end();
  
  

       i++ )

   - 第3处 -

 

3：这一处真是更为微妙。先增（preincrement）操作比后增（postincrement）操作效率更高，这是因为在进行后增（postincrement）操作时，对象不但必须自己递增，而且还要返回一个包含递增前之值的临时对象。要知道，就连int这样的内建类型也是如此！

 

[学习指导]：请使用先增（preincrement）操作，避免使用后增（postincrement）操作。

 

 

*              if( *i == name )
  
  

                                        -- 第4处 --

 

4：这里没有体现Employee类，但如果想让它行得通，则要么来一个转换成string的操作，要么通过一个转换构造函数（constructor）来得到一个string。然而两种方法都会产生临时对象，从而导致对string或者Employee的operator=之调用。（）

 

[学习指导]：时刻注意因为参数转换操作而产生的隐藏的临时对象。一个避免它的好办法就是尽可能显式（explicit）的使用构造函数（constructor）。

 

 

*       return "";

         -- 第5处 --

 

5：这里产生了一个临时的（空的）string对象。更好的做法是，声明一个局部string对象来储存返回值，然后用单独一个return语句返回这个string。这使得编译器可以在某些情况下（比如，形如“string a = FindAddr(l, “Harold”);”的代码）启用“返回值优化”处理来省略掉局部对象。

 

[规则]：请遵循所谓的“单入口/单出口”（single-entry/single-exit）规则。绝不要在一个函数里面写有多个return语句。

 

[作者记：当进行了进一步的性能测试之后，我不再认同上面的那条建议。我已经在《Exceptional C++》中修改了这一点。]

 

 

*      string FindAddr( list<Employee> l, string name )

--          第 * 处 --

 

* ：这可是一计遮眼法（red herring）。看上去，好像你可以很简单的通过把返回类型声明为string&而不是string，来避免在所有可能的返回问题中产生临时对象。对吗？错了！如果你的程序只是在代码试图使用引用（reference）的时候就崩溃（因为那个所指向的局部对象早已不存在），那就算你够走运的了！如果你不走运的话，你的代码将看上去似乎能够正常工作，却时不时的冷不防失败几次，从而使你不得不在调试程序的过程中渡过一个又一个漫漫长夜。

 

[规则]：绝对绝对（！）不要返回对局部对象的引用（reference）。

 

[作者记：有一些贴子正确的指出，你可以声明一个遇到错误时才返回的静态对象，从而实现在不改变函数语义的情况下返回一个引用（reference）。同时这也意味着，在返回引用（reference）的时候，你必须注意对象的生存周期。]

 

 

其实还有很多可以优化的地方，诸如“避免对end()进行多余的调用”等等。程序员可以（也应该）使用一个const_iterator。抛开这些不谈，我们仍可以得到如下的正确代码：

 

        string FindAddr( const list<Employee>& l, const string& name )
  
  

        {
  
  

             string addr;
  
  

             for( list<Employee>::const_iterator i = l.begin();
  
  

                 i != l.end();
  
  

                 ++i )
  
  

          {
  
  

                if( (*i).name == name )
  
  

                 {
  
  

              addr = (*i).addr;
  
  

break;
  
  

                 }
  
  

          }
  
  

          return addr;
  
  

        }

 

[kingofark注：

red herring: Something that draws attention away from the central issue.

a red herring: 遮眼法; 转移注意力的东西]