定义
它们看起来像函数，运作起来像函数，比宏（macro）要好得多，使用时还不需要承担函数调用的负担。当内联一个函数时，编译器可以对函数体执行特定环境下的优化工作，这样的优化对“正常”的函数调用时不可能的。
规则
inline关键字必须和函数体定义放在一起才可以实现内联，仅仅将inline放在函数声明之前不起任何作用。inline是一个用于实现的关键字而不是一个用于声明的关键字。对于类方法，定义在类内部的方法自动成为内联函数。
实现思想
内联函数的基本思想是将每个函数调用以它的代码体来替换，很可能会增加整个目标代码的体积，过分使用内联产生的程序会因为没有太大的体积导致可用空间不够。即使可以使用虚拟内存，内联所造成的代码膨胀也可能会导致不合理的页面调度行为（系统颠簸），这将使你的程序运行的很慢，过多的内联还会降低指令高速缓存的命中率，从而使取指令的速度降低，因为从主存取指令当然比缓存要慢。另一方面，如果内联函数体非常短，编译器为这个函数体生成的代码就会真的比为函数调用生成的代码要小的多，如果是这种情况，内联这个函数将会确实带来更小的目标代码和更高的缓存命中率。
inline指令就像register，它只是对编译器的一种提示，而不是命令。也就是说，只要编译器愿意，他就可以随意的忽略掉你的指令，事实上编译器常常会这么做。例如，大多数编译器会拒绝内联“复杂”的函数（例如包含循环和递归的函数）；还有，即使是最简单的虚函数调用，编译器的内联处理程序对它也爱莫能助（这一点也不奇怪，virtual的意思是“等到运行时再决定调用那个函数”，inline的意思是“在编译期间将调用之处用被调函数来替代”，如果编译器甚至不知道哪个函数将被调用，当然就不能责怪它拒绝生成内联调用了）。
问题及对应的解决规则
假设写了某个函数f并声明为inline，如果出于什么原因，编译器决定不对它内联，那将会发生些什么呢？最明显的一个回答是将f作为一个非内联函数来处理：为f生成代码时就象它是一个普通的”外联”函数一样， 对f的调用也象对普通函数调用那样进行。
理论上来说确实应该这样发生，但理论和现实往往会偏离，现在就属于这种情况。因为，这个方案对解决”被外联的内联”（outlined inline）这一问题确实非常理想，但它加入到c 标准中的时间相对较晚。较早的c 规范告诉编译器制造商去实现的是另外不同的行为，而且这一旧的行为在现在的编译器中还很普遍，所以必须理解它是怎么一
回事。
以上可以归结为：一个给定的内联函数是否真的被内联取决于所用的编译器的具体实现。幸运的是，大多数编译器都可以设置诊断级，当声明为内联的函数实际上并没有被内联时，编译器就会为你发出警告信息。
内联函数的定义实际上都是放在头文件中，这使得多个要编译的单元（源文件）可以包含同一个头文件，共享头文件内定义的内联函数所带来的益处。
//文件example.h
inline void f(){...} //f的定义
...
//文件source1.cpp
#include"example.h" //包含f的定义
... //包含对f的调用
//文件source2.cpp
#include"example.h" //包含f的定义
... //调用f问题：
假设现在采用旧的”被外联的内联”规则，而且假设f没有被内联，那么，当source1.cpp被编译时，生成的目标文件中将包含一个称为f的函数，就象f 没有被声明为inline一样。
同样地，当source2.cpp被编译时，产生的目标文件也将包含一个称为f的函数。当想把两个目标文件链接在一起时，编译器会因为程序中有两个f的定义而报错。在两个cpp文件编译生成的.obj文件中都存在”被外联的内联”方法f。
为了防止这一问题：
旧规则规定：
对于未被内联的内联函数，编译器把它当成被声明为static 那样处理，即，使它局限于当前被编译的文件。
具体到刚才看到的例子中，遵循旧规则的编译器处理source1.cpp中的f时，就象f在 source1.cpp中是静态的一样；处理source2.cpp中的f时，也把它当成在source2.cpp中是静态的一样。
这一策略消除了链接时的错误，但带来了开销：每个包含 f 的定义（以及调用 f ）的被编译单元都包含自己的 f 的静态拷贝。
如果 f 自身定义了局部静态变量，那么每个 f 的拷贝都有此局部变量的一份拷贝，这必将会让程序员大吃一惊，因为一般来说，函数中的“static”意味着“只有一份拷贝”。
新规则
将 f 作为一个非内联函数来处理：为 f 生成代码时就像它是一个普通的“外联”函数一样，对 f 的调用也像对普通函数调用那样进行。
无论新规则还是旧规则，如果内联函数没被内联，每个调用内联函数的地方还是得承担函数调用的开销；如果是旧规则，还得承受代码体积的增加，因为每个包含（或调用）f 的被编译单元都有一份 f 的代码及其静态变量的拷贝！（更糟糕的是，每个 f 的拷贝以及每个 f 的静态变量往往处于不同的虚拟内存页面，所以两个对 f 的不同拷贝进行调用可能导致多个页面错误）。
更多问题
有时编译器即使很想内联一个函数，却不得不为这个内联函数生成一个函数体。特别是，如果程序中要取一个内联函数的地址，编译器就必须为此生成一个函数体。编译器怎么能产生一个指向不存在的函数的指针呢？
inline void f(){...} //同上
void (*pf)() = f;
int main(){
f(); //对f的内联调用
pf(); //通过pf对f的非内联调用
}
这种情况很荒谬：f 的调用被内联了。
旧的规则：
每个取 f 地址的被编译单元还是各自生成了次函数的静态拷贝。
新规则下：
不管涉及的被编译单元有多少，将只生成唯一一个 f 的外部拷贝。
即使你从来不使用函数指针，这类”没被内联的内联函数”也会找上你的门，因为不只是程序员会使用函数指针，有时编译器也这么做。特别是，编译器有时会生成构造函数和析构函数的外部拷贝，这样就可以通过得到那些函数的指针，方便地构造和析构类的对象数组。
实际上，随便一个测试就可以证明构造函数和析构函数常常不适合内联；甚至，情况比测试结果还糟。例如，看下面这个类derived的构造函数：
class base{
public:
...
private:
string bm1, bm2;
};
class derived: public base{
public:
derived(){} //derived的构造函数是空的，但，真的是空的吗？
private:
string dm1, dm2, dm3;
}
这个构造函数看起来的确象个内联的好材料，因为它没有代码。但外表常常欺骗人！仅仅因为它没有代码？实际上，它含有相当多的代码。
c 就对象创建和销毁时发生的事件有多方面的规定。当使用new时，动态创建的对象将自动地被它们的构造函数初始化，当使用 delete时析构函数怎样被调用。当创建一个对象时，对象的每个基类以及对象的每个数据成员会被自动地创建；当对象被销毁时，会自动地执行相反的过程（即析构）。
c 规定了哪些必须发生，但没规定”怎么”发生。”怎么发生”取决于编译器的实现者，但要弄清楚的是，这些事件不是凭空自己发生的。程序中必然有什么代码使得它们发生，特别是那些由编译器的实现者写的、在编译其间插入到你的程序中的代码，必然也藏身于某个地方。有时，它们就藏身于你的构造函数和析构函数。
所以，对于上面那个号称为空的derived的构造函数，有些编译器会为它产生相当于下面的代码：
//一个derived构造函数的可能实现
derived::derived(){
//如果在堆上创建对象，为其分配堆内存
if(本对象在堆上)
this = ::operator new(sizeof(derived));
base::base(); //初始化base部分
dm1.string(); //构造dm1
dm2.string(); //构造dm2
dm3.string(); //构造dm3
}调用operator new（如果需要的话）的代码、构造基类部分的代码、构造数据成员的代码都会神不知鬼不觉地添加到你的构造函数中，从而增加构造函数的体积，使得构造函数不再适合内联。当然，同样的分析也适用于base的构造函数，如果base的构造函数被内联，添加到它里面的所有代码也会被添加到derived的构造函数（derived的构造函数会调用base的构造函数）。如果string的构造函数恰巧也被内联，derived的构造函数将得到其代码的5个拷贝，每个拷贝对应于derived对象中5个string中的一个（2个继承而来，3个自己声明）。现在你应该明白，内联derived的构造函数并非可以很简单就决定的！当然，类似的情况也适用于derived的析构函数，无论如何都要清楚这一点：被derived的构造函数初始化的所有对象都要被完全销毁。刚被销毁的对象以前可能占用了动态分配的内存，那么这些内存还需要释放。
内联函数的使用规则
程序库的设计者必须预先估计到声明内联函数带来的负面影响：想对程序库中的内联函数进行二进制代码升级是不可能的。换句话说，如果 f 是库中的一个内联函数，用户会将 f 的函数体编译到自己的程序中。如果程序库的设计者后来要修改 f ，所有使用f 的用户程序必须重新编译。相反，如果 f 是非内联函数，对 f 的修改仅需要用户重新链接，这就比需要重新编译大大减轻了负担；如果包含这个函数的程序库是被动态链接的，程序库的修改对用户来说完全是透明的。
内联函数中的静态对象常常表现出违反直觉的行为，如果函数中包含静态对象，通常要避免将它声明为内联函数。
一般来说，实际编程时最初的原则是不要内联任何函数，除非函数确实很小很简单，象下面这个age函数：
class person{
public:
int age() const {
return personage; }
...
private:
int personage;
...
};慎重地使用内联，不但给了调试器更多发挥作用的机会，还将内联的作用定位到了正确的位置：它是一个根据需要而使用的优化工具。不要忘了从无数经验得到的，一个程序往往花80%的时间来执行程序中20%的代码。这是一条很重要的定律，因为它提醒你，作为程序员的一个很重要的目标，就是找出这20%能够真正提高整个程序性能的代码。你可以选择内联你的函数，或者没必要就不内联，但这些选择只有作用在”正确”的函数上才有意义。 一旦找出了程序中那些重要的函数，以及那些内联后可以确实提高程序性能的函数（这些函数本身依赖于所在系统的体系结构），就要毫不犹豫地声明为inline。同时，要注意代码膨胀带来的问题，看看是否有内联函数没有被编译器内联。