在函数返回类型前加上关键字inline就可以将函数指定为内联函数：

1 inline const string& shortString(const string &s1, const string &s2) {2     return s1.size() < s2.size() ? s1 : s2;3 }

函数指定为内联函数，（通常）就是将它在程序调用点上”内联地“展开。假设我们将shortString定义为内联函数，则调用：

1 cout<
     
      <
     

在编译时展开为：

1 cout<<(s1.size() < s2.sizre()  ? s1 : s2)<

 　　

将函数声明为内联的方法：

　　1. 在函数返回类型前加inline（inline return_type function(parameters))。成员函数可以在声明时候添加inline也可以在定义时候添加inline。

　　2. 将成员函数定义在类定义式内，这个成员函数就被隐喻声明为inline.

 

内联说明（inline specification)对于编译器来说只是一个建议，编译器可以忽略这个建议。

 

将内联函数放入头文件内：　　

　　内联函数的定义应该在头文件中定义。因为大多数建置环境(build environments）在编译过程中进行inlining.而为了将一个“函数调用”替换为“被调用函数的本体”，编译器必须知道那个函数长什么样子。仅有函数声明是不够的；而且内联函数有可能在程序中定义不止一次，这时必须保证在所有源文件中，其定义是完全相同的。把内联函数的定义放在头文件中，可以确保在调用函数的时候所使用的定义是相同的。

 

 

内联函数的优点：　

　　可以避免调用函数的开销。当函数体比较小的时候，内联函数可以令目标代码更加高效。对于存取函数以及其他一些比较短的关键执行函数。

 

内联函数的缺点：

　　1. 由于将对函数的每一个调用都以函数本体替换之。所以会增加目标代码的大小。造成代码膨胀。这将导致程序体积太大，不利于在内存不大的机器上运行。

　　2. inline函数无法随着程序库的升级而升级。如果程序库中包含内联函数，一旦内联函数被改变，那么所有用到程序库的客户端程序都要重新编译。如果函数不　          是内联函数，一旦它有任何修改，客户端只需要重新连接就好，远比诚信编译的负担少的多。在头文件加入或修改内联函数时，使用该头文件的所有源文件都必          须重新编译。

　　3. 很多调试器无法调试内联函数。很多建置环境仅仅只能”在调试板程序中禁止发生inlining“

 

　　一般来说，内联机制适用于优化小的、只有几行的而且经常被调用的函数。一个比较得当的处理规则是，不要内联超过10行的函数。只有当函数10行甚至更少时才会将其定义为内联函数。

 

不适用的情况：

1. 大多数编译器不支持递归函数的内联

2. 包含循环或switch语句的函数是得不偿失的，除非在大多数情况下，这些循环或switch语句从不执行。

3. 虚函数

　　大部分编译器将太过复杂的函数inling，而所有堆virtual函数的调用（除非是最平淡无奇的）也都会使inling落空。因为virtual意味“等待，知道运行期才确定调用哪个函数”而inline意味着“执行前，先将调用动作替换为被执行函数的本体”。如果编译器不知道该调用哪个函数，你就很难责备它们拒绝将函数本体inlining。

4. 构造函数和析构函数

　　编译器会为构造函数和析构函数插入许多代码。