1.宏代码与内联函数区别
语言支持关系:
C 宏代码
C++ 宏代码 内联函数
宏代码本身不是函数,但使用起来象函数.预处理器用复制宏代码的方式代替函数调用,省去了参数压栈、生成汇编语言的CALL调用、返回参数、执行return 等过程,从而提高了速度.使用宏代码最大的缺点是容易出错,预处理器在复制宏代码时常常产生意想不到的边际效应.
对于任何内联函数,编译器在符号表里放入函数的声明(包括名字、参数类型、返回值类型).如果编译器没有发现内联函数存在错误,那么该函数的代码也被放入符号表里.在调用一个内联函数时,编译器首先检查调用是否正确(进行类型安全检查,或者进行自动类型转换,当然对所有的函数都一样).如果正确,内联函数的代码就会直接替换函数调用,于是省去了函数调用的开销.这个过程与预处理有显著的不同,因为预处理器不能进行类型安全检查,或者进行自动类型转换.假如内联函数是成员函数,对象的地址(this)会被放在合适的地方,这也是预处理器办不到的.
宏定义是预处理器在代码优化时直接替换的,而内联函数是在编译期间插入代码.宏定义替换比内联函数执行得早
内联函数使用方法:
关键字inline 必须与函数定义体放在一起才能使函数成为内联,仅将inline 放在函数声明前面不起任何作用.
正确使用方法:
void Foo(int x, int y);
inline void Foo(int x, int y) // inline 与函数定义体放在一起
{
…
}
错误使用方法:
inline void Foo(int x, int y); // inline 仅与函数声明放在一起
void Foo(int x, int y)
{
…
}
.在内联函数内不允许用循环语句和开关语句。
如果内联函数有这些语句，则编译将该函数视同普通函数那样产生函数调用代码,递归函数(自己调用自己的函数)是不能被用来做内联函数的。内联函数只适合于只有1～5行的小函数。对一个含有许多语句的大函数，函数调用和返回的开销相对来说微不足道，所以也没有必要用内联函数实现。
2.显式内联函数和隐式内联函数
a.在类声明的内部声明，而在类声明外部定义叫做显式内联函数，如：
class display
{
int t;
public:
void output(void)
}
display object;
inline void display::output(void)
{
cout << "i is " << i <<"/n";
}
b.在类声明的内部定义，叫做隐式内联函数，如：
class display
{
int t;
public:
inline void output(void)
{cout<<"i is "<< i << "/n";}
}
3.别人总结的 摘自 http://blog.sina.com.cn/s/blog_487de73e010007yl.html
文章（一）
内联函数与宏定义
在C中，常用预处理语句#define来代替一个函数定义。例如：
#define MAX(a，b) ((a)>(b)?(a):(b))
该语句使得程序中每个出现MAX(a,b)函数调用的地方都被宏定义中后面的表达式((a)>(b)?(a):(b))所替换。
宏定义语句的书写格式有过分的讲究， MAX与括号之间不能有空格，所有的参数都要
放在括号里。尽管如此，它还是有麻烦：
int a=1，b=0；
MAX(a++,b)； //a被增值2次
MAX(a++,b+10)； //a被增值1次
MAX(a,"Hello")； //错误地比较int和字符串，没有参数类型检查
MAX( )函数的求值会由于两个参数值的大小不同而产生不同的副作用。
MAX(a++,b)的值为2，同时a的值为3；
MAX(a++,b+10)的值为10，同时a的值为2。
如果是普通函数，则MAX(a,"HellO")会受到函数调用的检查，但此处不会因为两个参数类型不同而被编译拒之门外。幸运的是，通过一个内联函数可以得到所有宏的替换效能和所有可预见的状态以及常规函数的类型检查：
inline int MAX(int a，int b)
{
return a>b?a:b；
}
1.内联函数与宏的区别：
2.内联函数的使用：
注意：
总结：
文章（二）
8.5.1 用内联取代宏代码
C++ 语言支持函数内联，其目的是为了提高函数的执行效率（速度）。
在C程序中，可以用宏代码提高执行效率。宏代码本身不是函数，但使用起来象函数。预处理器用复制宏代码的方式代替函数调用，省去了参数压栈、生成汇编语言的CALL调用、返回参数、执行return等过程，从而提高了速度。使用宏代码最大的缺点是容易出错，预处理器在复制宏代码时常常产生意想不到的边际效应。例如
#define MAX(a, b)
语句
result = MAX(i, j) + 2 ;
将被预处理器解释为
result = (i) > (j) ? (i) : (j) + 2 ;
由于运算符‘+’比运算符‘:’的优先级高，所以上述语句并不等价于期望的
result = ( (i) > (j) ? (i) : (j) ) + 2 ;
如果把宏代码改写为
#define MAX(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不是函数，而是宏。（参见6.5节“使用断言”）
8.5.2 内联函数的编程风格
关键字inline必须与函数定义体放在一起才能使函数成为内联，仅将inline放在函数声明前面不起任何作用。如下风格的函数Foo不能成为内联函数：
inline void Foo(int x, int y);
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)
{
…
}
8.5.3 慎用内联
内联能提高函数的执行效率，为什么不把所有的函数都定义成内联函数？
如果所有的函数都是内联函数，还用得着“内联”这个关键字吗？
内联是以代码膨胀（复制）为代价，仅仅省去了函数调用的开销，从而提高函数的执行效率。如果执行函数体内代码的时间，相比于函数调用的开销较大，那么效率的收获会很少。另一方面，每一处内联函数的调用都要复制代码，将使程序的总代码量增大，消耗更多的内存空间。以下情况不宜使用内联：
（1）如果函数体内的代码比较长，使用内联将导致内存消耗代价较高。
（2）如果函数体内出现循环，那么执行函数体内代码的时间要比函数调用的开销大。
类的构造函数和析构函数容易让人误解成使用内联更有效。要当心构造函数和析构函数可能会隐藏一些行为，如“偷偷地”执行了基类或成员对象的构造函数和析构函数。所以不要随便地将构造函数和析构函数的定义体放在类声明中。
一个好的编译器将会根据函数的定义体，自动地取消不值得的内联（这进一步说明了inline不应该出现在函数的声明中）。
8.6 一些心得体会
C++ 语言中的重载、内联、缺省参数、隐式转换等机制展现了很多优点，但是这些优点的背后都隐藏着一些隐患。正如人们的饮食，少食和暴食都不可取，应当恰到好处。我们要辨证地看待C++的新机制，应该恰如其分地使用它们。虽然这会使我们编程时多费一些心思，少了一些痛快，但这才是编程的艺术。
4.循环语句、开关语句
不是内联函数中不能有循环语句，而是当内联函数中出现了复杂的逻辑控制语句后，编译器会不再认为它是一个内联函数。
也就是说，当内联函数中实现过于复杂时，编译器会将它作为一个普通函数处理。
这是由内联函数的特殊性所决定的，由于内联是调用处展开的方式，所以编译器认为只有足够简单的函数才可以具有该特性，复杂函数编译器会放弃内联特性。
5. 别人总结的(很好) 摘自 http://blog.sina.com.cn/s/blog_4a0e545d01000c4e.html
在C++语言的设计中，内联函数的引入可以说完全是为了性能的考虑。因此在编写对性能要求比较高的C++程序时，非常有必要仔细考量内联函数的使用。
所谓“内联”，即将被调用函数的函数体代码直接地整个插入到该函数被调用处，而不是通过call语句进行。当然，编译器在真正进行“内联”时，因为考虑到被内联函数的传入参数、自己的局部变量，以及返回值的因素，不仅仅只是进行简单的代码拷贝，还需要做很多细致的工作，但大致思路如此。
开发人员可以有两种方式告诉编译器需要内联哪些类成员函数，一种是在类的定义体外；一种是在类的定义体内。
（1）当在类的定义体外时，需要在该成员函数的定义前面加“inline”关键字，显式地告诉编译器该函数在调用时需要“内联”处理，如：
class Student
{
public:
private:
};
inline String GetName()
{
}
inline int GetAge()
{
}
inline void SetAge(int ag)
{
}
（2）当在类的定义体内且声明该成员函数时，同时提供该成员函数的实现体。此时，“inline”关键字并不是必需的，如：
class Student
{
public:
private:
};
当普通函数（非类成员函数）需要被内联时，则只需要在函数的定义时前面加上“inline”关键字，如：
{
}
因为C++是以 “编译单元”为单位编译的，而一个编译单元往往大致等于一个“.cpp”文件。在实际编译前，预处理器会将“#include”的各头文件的内容（可能会有递归头文件展开）完整地拷贝到cpp文件对应位置处（另外还会进行宏展开等操作）。预处理器处理后，编译真正开始。一旦C++编译器开始编译，它不会意识到其他cpp文件的存在。因此并不会参考其他cpp文件的内容信息。联想到内联的工作是由编译器完成的，且内联的意思是将被调用内联函数的函数体代码直接代替对该内联函数的调用。这也就意味着，在编译某个编译单元时，如果该编译单元会调用到某个内联函数，那么该内联函数的函数定义（即函数体）必须也包含在该编译单元内。因为编译器使用内联函数体代码替代内联函数调用时，必须知道该内联函数的函数体代码，而且不能通过参考其他编译单元信息来获得这一信息。
如果有多个编译单元会调用到某同一个内联函数，C++规范要求在这多个编译单元中该内联函数的定义必须是完全一致的，这就是“ODR”（one- definition rule）原则。考虑到代码的可维护性，最好将内联函数的定义放在一个头文件中，用到该内联函数的各个编译单元只需#include该头文件即可。进一步考虑，如果该内联函数是一个类的成员函数，这个头文件正好可以是该成员函数所属类的声明所在的头文件。这样看来，类成员内联函数的两种声明可以看成是几乎一样的，虽然一个是在类外，一个在类内。但是两个都在同一个头文件中，编译器都能在#include该头文件后直接取得内联函数的函数体代码。讨论完如何声明一个内联函数，来查看编译器如何内联的。继续上面的例子，假设有个foo函数：
#include "student.h"
...
void foo()
{
}
foo函数进入 foo函数时，从其栈帧中开辟了放置abc对象的空间。进入函数体后，首先对该处空间执行Student的默认构造函数构造abc对象。然后将常数12压栈，调用abc的SetAge函数（开辟SetAge函数自己的栈帧，返回时回退销毁此栈帧）。紧跟着执行abc的GetAge函数，并将返回值压栈。最后调用cout的<<操作符操作压栈的结果，即输出。
内联后大致如下:
#include "student.h"
...
void foo()
{
}
这时，函数调用时的参数压栈、栈帧开辟与销毁等操作不再需要，而且在结合这些代码后，编译器能进一步优化为如下结果：
#include "student.h"
...
void foo()
{
}
这显然是最好的优化结果；相反，考虑原始版本。如果SetAge/GetAge没有被内联，因为非内联函数一般不会在头文件中定义，这两个函数可能在这个编译单元之外的其他编译单元中定义。即foo函数所在编译单元看不到SetAge/GetAge，不知道函数体代码信息，那么编译器传入12给SetAge，然后用 GetAge输出。在这一过程中，编译器不能确信最后GetAge的输出。因为编译这个编译单元时，不知道这两个函数的函数体代码，因而也就不能做出最终版本的优化。
从上述分析中，可以看到使用内联函数至少有如下两个优点。
（1）减少因为函数调用引起开销，主要是参数压栈、栈帧开辟与回收，以及寄存器保存与恢复等。
（2）内联后编译器在处理调用内联函数的函数（如上例中的foo()函数）时，因为可供分析的代码更多，因此它能做的优化更深入彻底。前一条优点对于开发人员来说往往更显而易见一些，但往往这条优点对最终代码的优化可能贡献更大。
这时，有必要简单介绍函数调用时都需要执行哪些操作，这样可以帮助分析一些函数调用相关的问题。假设下面代码：
void foo()
{
}
调用者（这里是foo）在调用前需要执行如下操作。
（1）参数压栈：这里是a、b和c。压栈时一般都是按照逆序，因此是c->b->c。如果a、b和c有对象，则需要先进行拷贝构造（前面章节已经讨论）。
（2）保存返回地址：即函数调用结束返回后接着执行的语句的地址，这里是②处语句的地址。
（3）保存维护foo函数栈帧信息的寄存器内容：如SP（堆栈指针）和FP（栈帧指针）等。到底保存哪些寄存器与平台相关，但是每个平台肯定都会有对应的寄存器。
（4）保存一些通用寄存器的内容：因为有些通用寄存器会被所有函数用到，所以在foo调用func之前，这些寄存器可能已经放置了对foo有用的信息。这些寄存器在进入func函数体内执行时可能会被func用到，从而被覆写。因此foo在调用func前保存一份这些通用寄存器的内容，这样在func返回后可以恢复它们。
接着调用func函数，它首先通过移动栈指针来分配所有在其内部声明的局部变量所需的空间，然后执行其函数体内的代码等。
最后当func执行完毕，函数返回时，foo函数还需要执行如下善后处理。
（1）恢复通用寄存器的值。
（2）恢复保存foo函数栈帧信息的那些寄存器的值。
（3）通过移动栈指针，销毁func函数的栈帧，
（4）将保存的返回地址出栈，并赋给IP寄存器。
（5）通过移动栈指针，回收传给func函数的参数所占用的空间。
在前面章节中已经讨论，如果传入参数和返回值为对象时，还会涉及对象的构造与析构，函数调用的开销就会更大。尤其是当传入对象和返回对象是复杂的大对象时，更是如此。
因为函数调用的准备与善后工作最终都是由机器指令完成的，假设一个函数之前的准备工作与之后的善后工作的指令所需的空间为SS，执行这些代码所需的时间为TS，现在可以更细致地从空间与时间两个方面来分析内联的效果。
（1）在空间上，一般印象是不采用内联，被调用函数的代码只有一份，调用它的地方使用call语句引用即可。而采用内联后，该函数的代码在所有调用其处都有一份拷贝，因此最后总的代码大小比采用内联前要大。但事实不总是这样的，如果一个函数a的体代码大小为AS，假设a函数在整个程序中被调用了n次，不采用内联时，对a的调用只有准备工作与善后工作两处会增加最后的代码量开销，即a函数相关的代码大小为：n * SS + AS。采用内联后，在各处调用点都需要将其函数体代码展开，即a函数相关的代码大小为n * AS。这样比较二者的大小，即比较(n * SS + AS)与(n*AS)的大小。考虑到n一般次数很多时，可以简化成比较SS与AS的大小。这样可以得出大致结论，如果被内联函数自己的函数体代码量比因为函数调用的准备与善后工作引入的代码量大，内联后程序的代码量会变大；相反，当被内联函数的函数体代码量比因为函数调用的准备与善后工作引入的代码量小，内联后程序的代码量会变小。这里还没有考虑内联的后续情况，即编译器可能因为获得的信息更多，从而对调用函数的优化做得更深入和彻底，致使最终的代码量变得更小。
（2）在时间上，一般而言，每处调用都不再需要做函数调用的准备与善后工作。另外内联后，编译器在做优化时，看到的是调用函数与被调用函数连成的一大块代码。即获得的代码信息更多，此时它对调用函数的优化可以做得更好。最后还有一个很重要的因素，即内联后调用函数体内需要执行的代码是相邻的，其执行的代码都在同一个页面或连续的页面中。如果没有内联，执行到被调用函数时，需要跳到包含被调用函数的内存页面中执行，而被调用函数所属的页面极有可能当时不在物理内存中。这意味着，内联后可以降低“缺页”的几率，知道减少“缺页”次数的效果远比减少一些代码量执行的效果。另外即使被调用函数所在页面可能也在内存中，但是因为与调用函数在空间上相隔甚远，所以可能会引起“cache miss”，从而降低执行速度。因此总的来说，内联后程序的执行时间会比没有内联要少。即程序的速度更快，这也是因为内联后代码的空间 “locality”特性提高了。但正如上面分析空间影响时提到的，当AS远大于SS，且n非常大时，最终程序的大小会比没有内联时要大很多。代码量大意味着用来存放代码的内存页也会更多，这样因为执行代码而引起的“缺页”也会相应增多。如果这样，最终程序的执行时间可能会因为大量的“缺页”而变得更多，即程序的速度变慢。这也是为什么很多编译器对于函数体代码很多的函数，会拒绝对其进行内联的请求。即忽略“inline”关键字，而对如同普通函数那样编译。
综合上面的分析，在采用内联时需要内联函数的特征。比如该函数自己的函数体代码量，以及程序执行时可能被调用的次数等。当然，判断内联效果的最终和最有效的方法还是对程序的大小和执行时间进行实际测量，然后根据测量结果来决定是否应该采用内联，以及对哪些函数进行内联。
如下根据内联的本质来讨论与其相关的一些其他特点。
如前所述，因为调用内联函数的编译单元必须有内联函数的函数体代码信息。又因为ODR规则和考虑到代码的可维护性，所以一般将内联函数的定义放在一个头文件中，然后在每个调用该内联函数的编译单元中#include该头文件。现在考虑这种情况，即在一个大型程序中，某个内联函数因为非常通用，而被大多数编译单元用到对该内联函数的一个修改，就会引起所有用到它的编译单元的重新编译。对于一个真正的大型程序，重新编译大部分编译单元往往意味着大量的编译时间。因此内联最好在开发的后期引入，以避免可能不必要的大量编译时间的浪费。
再考虑这种情况，如果某开发小组在开发中用到了第三方提供的程序库，而这些程序库中包含一些内联函数。因为该开发小组的代码中在用到第三方提供的内联函数处，都是将该内联函数的函数体代码拷贝到调用处，即该开发小组的代码中包含了第三方提供代码的“实现”。假设这个第三方单位在下一个版本中修改了某些内联函数的定义，那么虽然这个第三方单位并没有修改任何函数的对外接口，而只是修改了实现，该开发小组要想利用这个新的版本，仍然需要重新编译。考虑到可能该开发小组的程序已经发布，那么这种重新编译的成本会相当高；相反，如果没有内联，并且仍然只是修改实现，那么该开发小组不必重新编译即可利用新的版本。
因为内联的本质就是用函数体代码代替对该函数的调用，所以考虑递归函数，如：
[inline] int foo(int n)
{
}
如果编译器编译某个调用此函数的编译单元，如：
void func()
{
}
考虑如下两种情况。
（1）如果在编译该编译单元且调用foo时，提供的参数n不能知道其实际值，则编译器无法知道对foo函数体进行多少次代替。在这种情况下，编译器会拒绝对foo函数进行内联。
（2）如果在编译该编译单元且调用foo时，提供的参数n能够知道其实际值，则编译器可能会视n值的大小来决定是否对foo函数进行内联。因为如果n很大，内联展开可能会使最终程序的大小变得很大。
如前所述，因为内联函数是编译期行为，而虚拟函数是执行期行为，因此编译器一般会拒绝对虚拟函数进行内联的请求。但是事情总有例外，内联函数的本质是编译器编译调用某函数时，将其函数体代码代替call调用，即内联的条件是编译器能够知道该处函数调用的函数体。而虚拟函数不能够被内联，也是因为在编译时一般来说编译器无法知道该虚拟函数到底是哪一个版本，即无法确定其函数体。但是在两种情况下，编译器是能够知道虚拟函数调用的真实版本的，因此虚拟函数可以被内联。
其一是通过对象，而不是指向对象的指针或者对象的引用调用虚拟函数，这时编译器在编译期就已经知道对象的确切类型。因此会直接调用确定的某虚拟函数实现版本，而不会产生“动态绑定”行为的代码。
其二是虽然是通过对象指针或者对象引用调用虚拟函数，但是编译时编译器能知道该指针或引用对应到的对象的确切类型。比如在产生的新对象时做的指针赋值或引用初始化，发生在于通过该指针或引用调用虚拟函数同一个编译单元并且二者之间该指针没有被改变赋值使其指向到其他不能确切知道类型的对象（因为引用不能修改绑定，因此无此之虞）。此时编译器也不会产生动态绑定的代码，而是直接调用该确定类型的虚拟函数实现版本。
在这两种情况下，编译器能够将此虚拟函数内联化，如：
inline virtual int x::y (char* a)
{
}
void z (char* b)
{
当然在实际开发中，通过这两种方式调用虚拟函数时应该非常少，因为虚拟函数的语义是“通过基类指针或引用调用，到真正运行时才决定调用哪个版本”。
从上面的分析中已经看到，编译器并不总是尊重“inline”关键字。即使某个函数用“inline”关键字修饰，并不能够保证该函数在编译时真正被内联处理。因此与register关键字性质类似，inline仅仅是给编译器的一个“建议”，编译器完全可以视实际情况而忽略之。
另外从内联，即用函数体代码替代对该函数的调用这一本质看，它与C语言中的函数宏（macro）极其相似，但是它们之间也有本质的区别。即内联是编译期行为，宏是预处理期行为，其替代展开由预处理器来做。也就是说编译器看不到宏，更不可能处理宏。另外宏的参数在其宏体内出现两次或两次以上时经常会产生副作用，尤其是当在宏体内对参数进行++或--操作时，而内联不会。还有，预处理器不会也不能对宏的参数进行类型检查。而内联因为是编译器处理的，因此会对内联函数的参数进行类型检查，这对于写出正确且鲁棒的程序，是一个很大的优势。最后，宏肯定会被展开，而用inline关键字修饰的函数不一定会被内联展开。
最后顺带提及，一个程序的惟一入口main()函数肯定不会被内联化。另外，编译器合成的默认构造函数、拷贝构造函数、析构函数，以及赋值运算符一般都会被内联化。
6.内联函数可以重载
最典型的例子就是内联的构造函数的重载
7.C++中，什么时候函数不能声明为内联函数？
如果在类中的所有虚函数都内声明为内联函数，启发式算法就会失败，大多数基于启发式算法的编译器会在每个使用它的object文件中生成一个类的vtbl。在大型系统里，这会导致程序包含同一个类的成百上千个vtbl拷贝！大多数遵循这种启发式算法的编译器会给你一些方法来人工控制vtbl的生成，但是一种更好的解决此问题的方法是避免把虚函数声明为内联函数
8.在内联函数中不能用数组？（有待证明）
1238
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
