<<c++primer>>中讲到:
inline函数
考虑下列 min()函数
int min( int v1, int v2 )
{
return( v1 < v2 << v1 : v2 );
}
为这样的小操作定义一个函数的好处是:
1.如果一段代码包含 min()的调用, 那么阅读这样的代码并解释它的含义
比读一个条件操作符的实例以及理解代码在做什么, 尤其是复杂表达式时要
容易得多
2.改变一个局部化的实现比更改一个应用中的 300 个出现要容易得多, 例
如 如果决 定测试条件应该是
( v1 == v2 || v1 < v2 )
那么 找到该代码的每一个出现将非常乏味而且容易出错
3.语义是统一的 每个测试都保证以相同的方式实现
4.函数可以被重用 不必为其他的应用重写代码
但是 将 min()写成函数有一个严重的缺点, 调用函数比直接计算条件操作
符要慢得多, 不但必须拷贝两个实参 ,保存机器的寄存器. 程序还必须转向一
个新位置 同此手写的条件操作符能快得多。
inline 内联函数给出了一种解决方案 ,若一个函数被指定为 inline 函
数 则它将在程序中每个调用点上被“ 内联地” 展开 。例如:
int minVal2 = min( i, j );
在编译时被展开为 :
int minVal2 = i < j << i : j;
把 min()写成函数的额外执行开销从而被消除了。
在函数声明或定义中的函数返回类型前加上关键字 inline, 即把 min()
指定成为 inline :inline int min( int v1, int v2 ) { /* ... */ }
但是 注意 inline 指示对编译器来说只是一个建议, 编译器可以选择忽
略该建议, 因为, 把一个函数声明为 inline 函数并不见得真的适合在调用
点上展开 ,例如, 一个递归函数 如 rgcd()并不能在调用点完全展开(虽然
它的第一个调用可以)。 一个1200行的函数也不太可能在调用点展开。 一般
地 inline 机制用来优化小的、 只有几行的、 经常被调用的函数。 在抽象
数据类的设计中, 它对支持信息隐藏起着主要作用。
inline 函数对编译器而言必须是可见的 ,以便它能够在调用点内联展开
该函数。 与非 inline 函数不同的是。 inline 函数必须在调用该函数的每
个文本文件中定义。 当然 ,对于同一程序的不同文件, 如果 inline 函数
出现的话 ,其定义必须相同 ,对于由两个文件 compute.C和 draw.C 构成的
程序来说, 程序员不能定义这样的 min()函数 ,它在 compute.C中指一件事
情, 而在 draw.C 中指另外一件事情。 如果两个定义不相同 ,程序将会有
未定义的行为 :编译器最终会使用这些不同定义中的哪一个作为非 inline
函数调用的定义是不确定的 因而程序的行为可能并不像你所期望的。
为保证不会发生这样的事情 ,建议把 inline 函数的定义放到头文件中
。 在每个调用该 inline 函数的文件中包含该头文件。 这种方法保证对每个
inline 函数只有一个定义, 且程序员无需复制代码, 并且不可能在程序的
生命期中引起无意的不匹配的事情 。
<<高质量c++编程指南>>这样讲到:
1.用内联取代宏代码
C++ 语言支持函数内联,其目的是为了提高函数的执行效率(速度) 。
在 C 程序中,可以用宏代码提高执行效率。宏代码本身不是函数,但使用
起来象函 数。预处理器用复制宏代码的方式代替函数调用,省去了参数压栈
、生成汇编语言的 CALL 调用、返回参数、执行 return 等过程,从而提高了
速度。使用宏代码最大的缺点是容 易出错,预处理器在复制宏代码时常常产
生意想不到的边际效应。例如
#define MAX(a, b) (a) > (b) ? (a) : (b)
语句
result = MAX(i, j) + 2 ;
将被预处理器解释为
result = (i) > (j) ? (i) : (j) + 2 ;
由于运算符‘+’比运算符‘:’的优先级高,所以上述语句并不等价于期
望的
result = ( (i) > (j) ? (i) : (j) ) + 2 ;
如果把宏代码改写为 #define MAX(a, b) ( (a) > (b) ? (a) :
(b) )
则可以解决由优先级引起的错误。但是即使使用修改后的宏代码也不是万
无一失的,例 如语句
result = MAX(i++, j);
将被预处理器解释为
result = (i++) > (j) ? (i++) : (j);
对于 C++ 而言,使用宏代码还有另一种缺点:无法操作类的私有数据成
员。
让我们看看 C++ 的“函数内联”是如何工作的。对于任何内联函数,编
译器在符号 表里放入函数的声明(包括名字、参数类型、返回值类型)。如
果编译器没有发现内联 函数存在错误,那么该函数的代码也被放入符号表里
。在调用一个内联函数时,编译器 首先检查调用是否正确(进行类型安全检
查,或者进行自动类型转换,当然对所有的函 数都一样)。如果正确,内联
函数的代码就会直接替换函数调用,于是省去了函数调用 的开销。这个过程
与预处理有显著的不同,因为预处理器不能进行类型安全检查,或者 进行自
动类型转换。假如内联函数是成员函数,对象的地址(this)会被放在合适的
地 方,这也是预处理器办不到的。
C++ 语言的函数内联机制既具备宏代码的效率,又增加了安全性,而且可
以自由操 作类的数据成员。所以在 C++ 程序中,应该用内联函数取代所有宏
代码,“断言 assert” 恐怕是唯一的例外。assert 是仅在 Debug 版本起作
用的宏,它用于检查“不应该”发生 的情况。为了不在程序的 Debug 版本和
Release 版本引起差别,assert 不应该产生任何 副作用。如果 assert 是函
数,由于函数调用会引起内存、代码的变动,那么将导致 Debug 版本与
Release 版本存在差异。所以 assert 不是函数,而是宏。
2.内联函数的编程风格
关键字 inline 必须与函数定义体放在一起才能使函数成为内联,仅将
inline 放在 函数声明前面不起任何作用。如下风格的函数 Foo 不能成为内
联函数:
inline void Foo(int x, int y); // inline 仅与函数声明放在一起
void Foo(int x, int y)
{
⋯
}
而如下风格的函数 Foo 则成为内联函数:
void Foo(int x, int y);
inline void Foo(int x, int y) // inline 与函数定义体放在一起
{
⋯
}
所以说,inline 是一种“用于实现的关键字”,而不是一种“用于
声明的关键字” 。 一般地,用户可以阅读函数的声明,但是看不到函数的定
义。尽管在大多数教科书中内 联函数的声明、定义体前面都加了 inline 关
键字,但我认为 inline 不应该出现在函数 的声明中。这个细节虽然不会影
响函数的功能,但是体现了高质量 C++/C 程序设计风格 的一个基本原则:声
明与定义不可混为一谈,用户没有必要、也不应该知道函数是否需 要内联。
定义在类声明之中的成员函数将自动地成为内联函数,例如
class A
{
public:
void Foo(int x, int y) { ⋯ } // 自动地成为内联函数
}
将成员函数的定义体放在类声明之中虽然能带来书写上的方便,但不是一
种良好的编程 风格,上例应该改成:
// 头文件
class A
{
public: void Foo(int x, int y);
}
// 定义文件
inline void A::Foo(int x, int y) { ⋯ }
3 慎用内联
内联能提高函数的执行效率,为什么不把所有的函数都定义成内联函数?
如果所有的函数都是内联函数,还用得着“内联”这个关键字吗?
内联是以代码膨胀(复制)为代价,仅仅省去了函数调用的开销,从而
提高函数的执行效率。如果执行函数体内代码的时间,相比于函数调用的开销
较大,那么效率的收 获会很少。另一方面,每一处内联函数的调用都要复制
代码,将使程序的总代码量增大, 消耗更多的内存空间。以下情况不宜使用
内联:
(1)如果函数体内的代码比较长,使用内联将导致内存消耗代价较高。
(2)如果函数体内出现循环,那么执行函数体内代码的时间要比函数调用
的开销大。
类的构造函数和析构函数容易让人误解成使用内联更有效。要当心构造
函数和析构 函数可能会隐藏一些行为,如“偷偷地”执行了基类或成员对象
的构造函数和析构函数。 所以不要随便地将构造函数和析构函数的定义体放
在类声明中。 一个好的编译器将会根据函数的定义体,自动地取消不值得的
内联(这进一步说明 了 inline 不应该出现在函数的声明中) 。
参考资料:<<c++primer>>
<<高质量c++编程指南>>