Guru of the Week 条款27:转呼叫函数

类别:VC语言 点击:0 评论:0 推荐:
GotW#27 转呼叫函数(Forwarding Functions)

难度:3 / 10

怎样将转呼叫函数写得最好?原本答案很简单,但我们已经知道C++语言近来发生了微妙的变化。

问题

转呼叫函数对于将任务传递给其它函数或对象时很有用,尤其当它们被设计得很高效时。

评论一下下面这个转呼叫函数。你试图修改它吗?如果是的话,怎么来?

    // file f.cpp

    #include "f.h"

    /*...*/

    bool f( X x ) {

        return g( x );

    }

(说明:本次GotW的目的之一是阐明在July [1997]于London加入到C++语言中的一个微妙改进所造成的后果。)

解答

转呼叫函数对于将任务传递给其它函数或对象时很有用,尤其当它们被设计得很高效时。

关键点是:效率。

评论一下下面这个转呼叫函数。你试图修改它吗?如果是的话,怎么来?

    // file f.cpp

    #include "f.h"

    /*...*/

    bool f( X x ) {

        return g( x );

    }

有两个主要改进可使得这个函数更高效。第一个应该总被采用,第二个需要权衡。

1.传参时使用传const的引用代替传值

“这不会造成混乱吗?”你可能会问。不,它不会,至少在这种情况下。直到最近,C++语言才规定:因为编译器可以确保参数x除了被传递给g()外没有被其它地方使用,编译器可以将x完全优化掉。例如,这样的代码:

    X my_x;

    f( my_x );

编译器可以:

a)产生一个my_x的拷贝供f()使用(就是f()的代码体中的形参x),然后将这个拷贝传给g();或者

b)直接将my_x传给g()而不生成拷贝,因为它注意到这个额外的拷贝除了作g()的参数外根本没被使用。

后者更高效,不是吗?这是编译器试图作的优化,不是吗?

是的,是的,但只到July 1997的London会议。在那次会议上,“限制编译器作这种取消额外拷贝的优化”的提案得到了更多的支持。〖注1〗编译器唯一可以取消额外拷贝构造的地方是“返回值优化”(在你的C++宝典中查询细节吧)和“临时对象”。

这意味着,象f这样的转呼叫函数,编译器被要求产生两份拷贝。既然我们(作为f的作者)知道这个额外的拷贝不是必须的,我们应该按照通常的办法将x申明为const X&型的参数。

(注意:如果我们一直就是这么做的,而不是依赖于知道编译器被允许做些什么,那么,这个规则的变化不会对我们造成任何影响。这就是一个“简单就是美”例子--尽可能避开语言的细枝末节,别耍小聪明。)

2.函数内联

这个需要权衡。要之,默认将所有函数都实现为外联,有选择地将确实需要内联以提高效率的函数实现为内联。

当你将函数内联时,积极面是你避免了对f函数的调用的额外开销。

消极面是内联f暴露了f的实现,并使得用户的代码依赖于此实现,当f被改变时,所有的用户代码都必须被重编译。更严重的是,用户代码现在至少需要知道函数g()的原型,这有点恶心,因为用户根本没有直接调用函数g,原本可以根本不需要知道它的原型的(至少,从我们的例子上,是这样的)。于是,如果g()自己发生了变化,接受其它类型的其它参数时,用户的代码将变得也需要知道这些类型的申明。

内联和非内联都可以。必须在优缺点间进行权衡,取决于f现在是怎样被使用的以及使用的广泛程度,和将来可能变为怎样被使用的以及使用的广泛程度。

GotW给出的代码规范:

l         传参时,用传const的引用来代替传值

l         避免函数内联,除非profiler告诉你有这个必要(程序员在猜测效能瓶颈点方面是很不准的)

 

注1:这个改进是必要的,它避免了编译器未经允许地省略拷贝构造时带来问题,尤其当拷贝构造有副作用时。很多时候,代码需要计算对象的拷贝数目。

本文地址:http://com.8s8s.com/it/it2370.htm