（一）inline函数（摘自C++ Primer的第三版）       在函数声明或定义中函数返回类型前加上关键字inline即把min（）指定为内联。       inline int min(int first, int secend) {/****/};         inline函数对编译器而言必须是可见的，以便它能够在调用点内展开该函数。与非inline函数不同的是，inline函数必须在调用该函数的每个文本文件中定义。当然，对于同一程序的不同文件，如果inline函数出现的话，其定义必须相同。对于由两个文件compute.C和draw.C构成的程序来说，程序员不能定义这样的min()函数，它在compute.C中指一件事情，而在draw.C中指另外一件事情。如果两个定义不相同，程序将会有未定义的行为.         为保证不会发生这样的事情，建议把inline函数的定义放到头文件中。在每个调用该inline函数的文件中包含该头文件。这种方法保证对每个inline函数只有一个定义，且程序员无需复制代码，并且不可能在程序的生命期中引起无意的不匹配的事情。 （二）内联函数的编程风格(摘自高质量C++/C 编程指南) 关键字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){} 慎用内联内联能提高函数的执行效率，为什么不把所有的函数都定义成内联函数？如果所有的函数都是内联函数，还用得着“内联”这个关键字吗？内联是以代码膨胀（复制）为代价，仅仅省去了函数调用的开销，从而提高函数的执行效率。如果执行函数体内代码的时间，相比于函数调用的开销较大，那么效率的收获会很少。另一方面，每一处内联函数的调用都要复制代码，将使程序的总代码量增大，消耗更多的内存空间。以下情况不宜使用内联：（1）如果函数体内的代码比较长，使用内联将导致内存消耗代价较高。（2）如果函数体内出现循环，那么执行函数体内代码的时间要比函数调用的开销大。类的构造函数和析构函数容易让人误解成使用内联更有效。要当心构造函数和析构函数可能会隐藏一些行为，如“偷偷地”执行了基类或成员对象的构造函数和析构函数。所以不要随便地将构造函数和析构函数的定义体放在类声明中。一个好的编译器将会根据函数的定义体，自动地取消不值得的内联（这进一步说明了inline 不应该出现在函数的声明中）。 C++ 语言支持函数内联，其目的是为了提高函数的执行效率（速度）。在C程序中，可以用宏代码提高执行效率。宏代码本身不是函数，但使用起来象函数。预处理器用复制宏代码的方式代替函数调用，省去了参数压栈、生成汇编语言的CALL调用、 返回参数、执行return等过程，从而提高了速度。 使用宏代码最大的缺点是容易出错，预处理器在复制宏代码时常常产生意想不到的边际效应。 对于C++ 而言，使用宏代码还有另一种缺点：无法操作类的私有数据成员。 让我们看看C++ 的"函数内联"是如何工作的。 对于任何内联函数，编译器在符号表里放入函数的声明（包括名字、参数类型、返回值类型）。 如果编译器没有发现内联函数存在错误，那么该函数的代码也被放入符号表里。 在调用一个内联函数时，编译器首先检查调用是否正确 （进行类型安全检查，或者进行自动类型转换，当然对所有的函数都一样）。 如果正确，内联函数的代码就会直接替换函数调用，于是省去了函数调用的开销。这个过程与预处理有显著的不同，因为预处理器不能进行类型安全检查，或者进行自动类型转换。 假如内联函数是成员函数，对象的地址（this）会被放在合适的地方，这也是预处理器办不到的。 C++ 语言的函数内联机制既具备宏代码的效率，又增加了安全性，而且可以自由操作类的数据成员。 所以在C++ 程序中，应该用内联函数取代所有宏代码，"断言assert"恐怕是唯一的例外。 assert是仅在Debug版本起作用的宏，它用于检查"不应该"发生的情况。 为了不在程序的Debug版本和Release版本引起差别，assert不应该产生任何副作用。 如果assert是函数，由于函数调用会引起内存、代码的变动，那么将导致Debug版本与Release版本存在差异。 所以assert不是函数，而是宏。

C++语言新增关键字 inline，用于将一个函数声明为内联函数。在程序编译时，编译器会将内联函数调用处用函数体替换，这一点类似于C语言中的宏扩展。 采用内联函数可以有效避免函数调用的开销，程序执行效率更高。使用内联函数的缺点就是，如果被声明为内联函数的函数体非常大，则编译器编译后程序的可执行码将会变得很大。另外，如果函数体内出现循环或者其它复杂的控制结构的时候，这个时候处理这些复杂控制结构所花费的时间远大于函数调用所花的时间，因此如果将这类函数声明为内联函数，意义不大，反而会使得编译后可执行代码边长。 通常在程序设计过程中，我们会将一些频繁被调用的短小函数声明为内联函数。 为了使得inline声明内联函数有效，我们必须将inline关键字与函数体放在一起才行，否则inline关键字是不能成功将函数声明内联函数的。如例1所示，inline关键字则无丝毫作用，而例2中则成功将swap函数声明为了一个内联函数。 [例1] inline 关键字放在函数声明处不会起作用： inline void swap(int &a, int &b); void swap(int &a, int &b) { int temp = a; a = b; b = temp; } [例2] inline 关键字应该与函数体放在一起： void swap(int &a, int &b); inline void swap(int &a, int &b) { int temp = a; a = b; b = temp; }

C++ inline 函数 （一）inline函数（摘自C++ Primer的第三版） inline int min(int first, int secend) {/****/}; inline 函数对编译器而言必须是可见的，以便它能够在调用点内展开该函数。与非inline函数不同的是，inline函数必须在调用该函数的每个文本文件中定义。当然，对于同一程序的不同文件，如果inline函数出现的话，其定义必须相同。对于由两个文件compute.C和draw.C构成的程序来说，程序员不能定义这样的min()函数，它在compute.C中指一件事情，而在draw.C中指另外一件事情。如果两个定义不相同，程序将会有未定义的行为： 为保证不会发生这样的事情，建议把inline函数的定义放到头文件中。在每个调用该inline函数的文件中包含该头文件。这种方法保证对每个inline函数只有一个定义，且程序员无需复制代码，并且不可能在程序的生命期中引起无意的不匹配的事情。 （二）内联函数的编程风格(摘自高质量C++/C 编程指南) 关键字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){} 慎用内联 内联能提高函数的执行效率，为什么不把所有的函数都定义成内联函数？如果所有的函数都是内联函数，还用得着“内联”这个关键字吗？内联是以代码膨胀（复制）为代价，仅仅省去了函数调用的开销，从而提高函数的执行效率。如果执行函数体内代码的时间，相比于函数调用的开销较大，那么效率的收获会很少。另一方面，每一处内联函数的调用都要复制代码，将使程序的总代码量增大，消耗更多的内存空间。 以下情况不宜使用内联： （1）如果函数体内的代码比较长，使用内联将导致内存消耗代价较高。 （2）如果函数体内出现循环，那么执行函数体内代码的时间要比函数调用的开销大。类的构造函数和析构函数容易让人误解成使用内联更有效。要当心构造函数和析构函数可能会隐藏一些行为，如“偷偷地”执行了基类或成员对象的构造函数和析构函数。所以不要随便地将构造函数和析构函数的定义体放在类声明中。一个好的编译器将会根据函数的定义体，自动地取消不值得的内联（这进一步说明了 inline 不应该出现在函数的声明中）。 注意点: 内联函数既能够去除函数调用所带来的效率负担又能够保留一般函数的优点。然而，内联函数并不是万能药，在一些情况下，它甚至能够降低程序的性能。因此在使用的时候应该慎重。 1．我们先来看看内联函数给我们带来的好处：从一个用户的角度来看，内联函数看起来和普通函数一样，它可以有参数和返回值，也可以有自己的作用域，然而它却不会引入一般函数调用所带来的负担。另外，它可以比宏更安全更容易调试。 当然有一点应该意识到，inline specifier仅仅是对编译器的建议，编译器有权利忽略这个建议。那么编译器是如何决定函数内联与否呢？一般情况下关键性因素包括函数体的大小，是否有局部对象被声明，函数的复杂性等等。 2．那么如果一个函数被声明为inline但是却没有被内联将会发生什么呢？理论上，当编译器拒绝内联一个函数的时候，那个函数会像普通函数一样被对待，但是还会出现一些其他的问题。 这里想要说的是，内联函数并不是一个增强性能的灵丹妙药。只有当函数非常短小的时候它才能得到我们想要的效果，但是如果函数并不是很短而且在很多地方都被调用的话，那么将会使得可执行体的体积增大。最令人烦恼的还是当编译器拒绝内联的时候。在老的实现中，结果很不尽人意，虽然在新的实现中有很大的改善，但是仍然还是不那么完善的。一些编译器能够足够的聪明来指出哪些函数可以内联哪些不能，但是，大多数编译器就不那么聪明了，因此这就需要我们的经验来判断。如果内联函数不能增强行能，就避免使用它！ 原文 http://www.cnblogs.com/berry/articles/1582702.html

C++内联函数详解 1.函数调用原理 "编译过程的最终产品是可执行程序--由一组机器语言指令组成。运行程序时，操作系统将这些指令载入计算机内存中，因此每条指令都有特定的内存地址。计算机随后将逐步执行这些指令。有时（如有循环和分支语句时），将跳过一些指令，向前或向后跳到特定地址。常规函数调用也使程序跳到另一个地址（函数的地址），并在函数结束时返回。下面更详细地介绍这一过程的典型实现。执行到函数调用指令时，程序将在函数调用后立即存储该指令的内存地址，并将函数参数复制到堆栈（为此保留的内存块），跳到标记函数起点的内存单元，执行函数代码（也许还需将返回值放入寄存器中），然后跳回到地址被保存的指令处（这与阅读文章时停下来看脚注，并在阅读完脚注后返回到以前阅读的地方类似）。来回跳跃并记录跳跃位置意味着以前使用函数时，需要一定的开销。" 2.内联函数 内联函数提供了另一种选择。编译器将使用相应的函数代码替换函数调用。因此，内联函数的运行速度比常规函数稍快，但代价是需要占用更多内存。 3.内联函数的使用 在函数声明前加上关键字inline; 在函数定义前加上关键字inline。 示例如下： #include<iostream> inline double square(double x){return x*x;} int main() { using namespace std; double a,b; double c = 13.0; a = square(5.0); b = square(4.5+7.5); cout<<"a="<<a<<",b="<<b<<endl; cout<<"c="<<c<<endl; cout<<"c squared="<<square(c++)<<endl; cout<<"now c="<<c<<endl; return 0; } 程序输出结果如下： a=25,b=144 c=13 c square=169 now c=14 4.内联函数与宏定义的区别 C语言使用预处理器语句#define来提供宏。如下例所示： #define SQUARE(X) X*X 宏定义时通过文本替换开实现的--X是参数的符号标记。 a = square(5.0);->a=5.0*5.0; b = square(4.5+7.5);->b=4.5+7.5*4.5+7.5 d = square(c++);->d=c++*c++ 可以看出，对于b，需要使用括号才能正常运算。 #define SQUARE(X) ((X)*(X)) 对于c,却仍递增了两次。 因此，宏定义和内联函数存在本质的区别，转换的时候应考虑是否转换后功能是否正常。 5.什么时候使用内联函数 如果执行函数代码的时间比处理函数调用机制的时间长，则节省的时间占比很小。若代码执行时间很短，则内联函数就可以节省函数调用的时间。   参考资料：《C++ Primer.Plus》 pp.253-255 原文地址http://www.bieryun.com/2956.html

 我们曾经在讨论C++的时候，经常会问到：“虚函数能被声明为内联吗？”现在，我们几乎听不到这个问题了。现在听到的是：“你不应该使print成为内联的。声明一个虚函数为内联是错误的！” 　　这种说法的两个主要的原因是（1）虚函数是在运行期决议而内联是一个编译期动作，所以，我们将虚函数声明为内联并得不到什么效果；（2）声明一个虚函数为内联导致了函数的多分拷贝，而且我们为一个不应该在任何时候内联的函数白白花费了存储空间。这样做很没脑子。 　　不过，事实并不是这样。我们先来看看第一个：许多情况下，虚拟函数都被静态地决议了——比如在派生类虚拟函数中调用基类的虚拟函数的时候。为什么这样做呢？封装。一个比较明显的例子就是派生类析构函数调用链。所有的虚析构函数，除了最初触发这个析构链的虚析构函数，都被静态的决议了。如果不将基类的虚析构函数内联，我们无法从中获利[a]。这和不内联一个虚拟析构函数有什么不同吗？如果继承体系层次比较深并且有许多这样的类的实例要被销毁的话，答案是肯定的。 　　再来看另外一个不用析构函数的例子，想象一下设计一个图书馆类。我们将MaterialLocation作为抽象类LibraryMaterial的一个成员。将它的print成员函数声明为一个纯虚函数，并且提供函数定义：它输出MaterialLocation。 　　class LibraryMaterial      {     　            private: 　　     MaterialLocation _loc; // shared data 　　// … 　　     public: 　　// declares pure virtual function 　     　inline virtual void print(ostream& = cout) = 0;      }; 　　// we actually want to encapsulate the handling of the 　　// location of the material within a base class 　　// LibraryMaterial print（） method - we just don’t want it 　　// invoked through the virtual interface. That is, it is 　　// only to be invoked within a derived class print（） method 　　inline void 　　LibraryMaterial:: 　　print(ostream &os)      {           os <<_loc;      } 　　接着，我们引入一个Book类，它的print函数输出Title, Author等等。在这之前，它调用基类的print函数（LibraryMaterial::print（））来显示书本位置（MaterialLocation）。如下： 　　inline void 　　Book:: 　　print(ostream &os) 　　{ 　　// ok, this is resolved statically, 　　// and therefore is inline expanded … 　      　LibraryMaterial::print()； 　      　os  << "title:"  << _title 　      　<< "author" << _author << endl; 　　} 　　AudioBook类，派生于Book类，并加入附加信息，比如旁述，音频格式等等。这些东西都用它的print函数输出。再这之前，我们需要调用Book::print（）来显示前面的信息。 　　inline void 　　AudioBook:: 　　print(ostream &os) 　　{ 　　// ok, this is resolved statically, 　　// and therefore is inline expanded … 　        　Book::print(); 　　        os <<"narrator:"<< _narrator <<endl; 　　} 　　这和虚析构函数调用链的例子一样，都只是最初调用的虚函数没有被静态决议，其它的都被原地展开。This unnamed hierarchical design pattern is significantly less effective if we never declare a virtual function to be inline. 　　那么对于第二个原因中代码膨胀的问题呢？我们来分析一下，如果我们写下： 　　LibraryMaterial *p = 　　new AudioBook("Mason & Dixon", 　　"Thomas Pynchon", "Johnny Depp"); 　　// … 　　p->print()； 　　这个print实例是内联的吗？不，当然不是。这样不得不通过虚拟机制在运行期决议。这让print实例放弃了对它的内联声明了吗？也不是。这个调用转换为下面的形式（伪代码）： 　　// Pseudo C++ Code 　　// Possible transformation of p->print（） 　　(*p->_vptr[ 2 ])(p); 　　where 2 represents the location of print within the associated virtual function table.因为调用print是通过函数指针_vptr[2]进行的，所以，编译器不能静态的决定这个调用地址，并且，这个函数也不能内联。 　　当然，虚函数print的内联实体（definition）也必须在某个地方表现出来。 即是说，至少有一个函数实体是在virtual table调用的地址原地展开的。编译器是如何决定在何时展开这个函数实体呢？其中一个编译（implementaion）策略是当virtual table生成的同时，生成这个函数实体。这就是说对于每一个派生类的virtual table都会生成一个函数实体。 　　在一个可应用的类[b]中有多少vitrual table会被生成呢？呵呵，这是一个好问题。C++标准中对虚函数行为进行了规定，但是没有对函数实现进行规定。由于virtual table没有在C++标准中进行规定，很明显，究竟这个virtual table怎样生成，和究竟要生成多少个vitrual table也没有规定。多少个？当然，我们只要一个。Stroustrup的cfront编译器，很巧妙的处理了这些情况。（ Stan and Andy Koenig described the algorithm in the March 1990 C++ Report article, "Optimizing Virtual Tables in C++ Release 2.0."） 　　Moreover, the C++ Standard now requires that inline functions behave as though only one definition for an inline function exists in the program even though the function may be defined in different files。新的规则要求编译器只展开一个内联虚函数。如果一点被广泛采用的话，虚函数的内联导致的代码膨胀问题就会消失。

 我们曾经在讨论C++的时候，经常会问到：“虚函数能被声明为内联吗？”现在，我们几乎听不到这个问题了。现在听到的是：“你不应该使print成为内联的。声明一个虚函数为内联是错误的！” 　　这种说法的两个主要的原因是（1）虚函数是在运行期决议而内联是一个编译期动作，所以，我们将虚函数声明为内联并得不到什么效果；（2）声明一个虚函数为内联导致了函数的多分拷贝，而且我们为一个不应该在任何时候内联的函数白白花费了存储空间。这样做很没脑子。 　　不过，事实并不是这样。我们先来看看第一个：许多情况下，虚拟函数都被静态地决议了——比如在派生类虚拟函数中调用基类的虚拟函数的时候。为什么这样做呢？封装。一个比较明显的例子就是派生类析构函数调用链。所有的虚析构函数，除了最初触发这个析构链的虚析构函数，都被静态的决议了。如果不将基类的虚析构函数内联，我们无法从中获利[a]。这和不内联一个虚拟析构函数有什么不同吗？如果继承体系层次比较深并且有许多这样的类的实例要被销毁的话，答案是肯定的。 　　再来看另外一个不用析构函数的例子，想象一下设计一个图书馆类。我们将MaterialLocation作为抽象类LibraryMaterial的一个成员。将它的print成员函数声明为一个纯虚函数，并且提供函数定义：它输出MaterialLocation。 　　class LibraryMaterial      {     　            private: 　　     MaterialLocation _loc; // shared data 　　// … 　　     public: 　　// declares pure virtual function 　     　inline virtual void print(ostream& = cout) = 0;      }; 　　// we actually want to encapsulate the handling of the 　　// location of the material within a base class 　　// LibraryMaterial print（） method - we just don’t want it 　　// invoked through the virtual interface. That is, it is 　　// only to be invoked within a derived class print（） method 　　inline void 　　LibraryMaterial:: 　　print(ostream &os)      {           os <<_loc;      } 　　接着，我们引入一个Book类，它的print函数输出Title, Author等等。在这之前，它调用基类的print函数（LibraryMaterial::print（））来显示书本位置（MaterialLocation）。如下： 　　inline void 　　Book:: 　　print(ostream &os) 　　{ 　　// ok, this is resolved statically, 　　// and therefore is inline expanded … 　      　LibraryMaterial::print()； 　      　os  << "title:"  << _title 　      　<< "author" << _author << endl; 　　} 　　AudioBook类，派生于Book类，并加入附加信息，比如旁述，音频格式等等。这些东西都用它的print函数输出。再这之前，我们需要调用Book::print（）来显示前面的信息。 　　inline void 　　AudioBook:: 　　print(ostream &os) 　　{ 　　// ok, this is resolved statically, 　　// and therefore is inline expanded … 　        　Book::print(); 　　        os <<"narrator:"<< _narrator <<endl; 　　} 　　这和虚析构函数调用链的例子一样，都只是最初调用的虚函数没有被静态决议，其它的都被原地展开。This unnamed hierarchical design pattern is significantly less effective if we never declare a virtual function to be inline. 　　那么对于第二个原因中代码膨胀的问题呢？我们来分析一下，如果我们写下： 　　LibraryMaterial *p = 　　new AudioBook("Mason & Dixon", 　　"Thomas Pynchon", "Johnny Depp"); 　　// … 　　p->print()； 　　这个print实例是内联的吗？不，当然不是。这样不得不通过虚拟机制在运行期决议。这让print实例放弃了对它的内联声明了吗？也不是。这个调用转换为下面的形式（伪代码）： 　　// Pseudo C++ Code 　　// Possible transformation of p->print（） 　　(*p->_vptr[ 2 ])(p); 　　where 2 represents the location of print within the associated virtual function table.因为调用print是通过函数指针_vptr[2]进行的，所以，编译器不能静态的决定这个调用地址，并且，这个函数也不能内联。 　　当然，虚函数print的内联实体（definition）也必须在某个地方表现出来。 即是说，至少有一个函数实体是在virtual table调用的地址原地展开的。编译器是如何决定在何时展开这个函数实体呢？其中一个编译（implementaion）策略是当virtual table生成的同时，生成这个函数实体。这就是说对于每一个派生类的virtual table都会生成一个函数实体。 　　在一个可应用的类[b]中有多少vitrual table会被生成呢？呵呵，这是一个好问题。C++标准中对虚函数行为进行了规定，但是没有对函数实现进行规定。由于virtual table没有在C++标准中进行规定，很明显，究竟这个virtual table怎样生成，和究竟要生成多少个vitrual table也没有规定。多少个？当然，我们只要一个。Stroustrup的cfront编译器，很巧妙的处理了这些情况。（ Stan and Andy Koenig described the algorithm in the March 1990 C++ Report article, "Optimizing Virtual Tables in C++ Release 2.0."） 　　Moreover, the C++ Standard now requires that inline functions behave as though only one definition for an inline function exists in the program even though the function may be defined in different files。新的规则要求编译器只展开一个内联虚函数。如果一点被广泛采用的话，虚函数的内联导致的代码膨胀问题就会消失。

原文链接：http://www.cnblogs.com/berry/articles/1582702.html inline函数（摘自C++ Primer的第三版） 在函数声明或定义中函数返回类型前加上关键字inline即把函数指定为内联。       inline int min(int first, int secend) {/****/};       inline 函数对编译器而言必须是可见的，以便它能够在调用点内展开该函数。与非inline函数不同的是，inline函数必须在调用该函数的每个文本文件中定义。当然，对于同一程序的不同文件，如果inline函数出现的话，其定义必须相同。对于由两个文件compute.C和draw.C构成的程序来说，程序员不能定义这样的min()函数，它在compute.C中指一件事情，而在draw.C中指另外一件事情。如果两个定义不相同，程序将会有未定义的行为。       为保证不会发生这样的事情，建议把inline函数的定义放到头文件中。在每个调用该inline函数的文件中包含该头文件。这种方法保证对每个inline函数只有一个定义，且程序员无需复制代码，并且不可能在程序的生命期中引起无意的不匹配的事情。 内联函数的编程风格(摘自高质量C++/C 编程指南) 关键字inline 必须与函数定义体放在一起才能使函数成为内联，仅将inline 放在函数声明前面不起任何作用。 如下风格的函数Foo 不能成为内联函数： inline void Foo(int x, int y); // inline 仅与函数声明放在一起 void Foo(int x, int y){} 而如下风格的函数Foo 则成为内联函数： inline void Foo(int x, int y) {} 所以说，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){} 慎用内联 内联能提高函数的执行效率，为什么不把所有的函数都定义成内联函数？如果所有的函数都是内联函数，还用得着“内联”这个关键字吗？内联是以代码膨胀（复制）为代价，仅仅省去了函数调用的开销，从而提高函数的执行效率。如果执行函数体内代码的时间，相比于函数调用的开销较大，那么效率的收获会很少。另一方面，每一处内联函数的调用都要复制代码，将使程序的总代码量增大，消耗更多的内存空间。 如果函数体内的代码比较长，使用内联将导致内存消耗代价较高。如果函数体内出现循环，那么执行函数体内代码的时间要比函数调用的开销大。类的构造函数和析构函数容易让人误解成使用内联更有效。要当心构造函数和析构函数可能会隐藏一些行为，如“偷偷地”执行了基类或成员对象的构造函数和析构函数。所以不要随便地将构造函数和析构函数的定义体放在类声明中。一个好的编译器将会根据函数的定义体，自动地取消不值得的内联（这进一步说明了 inline 不应该出现在函数的声明中）。 内联函数既能够去除函数调用所带来的效率负担又能够保留一般函数的优点。然而，内联函数并不是万能药，在一些情况下，它甚至能够降低程序的性能。因此在使用的时候应该慎重。         1．我们先来看看内联函数给我们带来的好处：从一个用户的角度来看，内联函数看起来和普通函数一样， 它可以有参数和返回值，也可以有自己的作用域，然而它却不会引入一般函数调用所带来的负担。另外， 它可以比宏更安全更容易调试。        当然有一点应该意识到，inline   specifier仅仅是对编译器的建议，编译器有权利忽略这个建议。那么编译器是如何决定函数内联与否呢？一般情况下关键性因素包括函数体的大小，是否有局部对象被声明，函数的复杂性等等。         2．那么如果一个函数被声明为inline但是却没有被内联将会发生什么呢？理论上，当编译器拒绝内联一个   函数的时候，那个函数会像普通函数一样被对待，但是还会出现一些其他的问题。例如下面这段代码：     // filename Time.h #include<ctime> #include<iostream> using namespace std; class Time { public: inline void Show() { for (int i = 0; i<10; i++) cout<<time(0)<<endl; } };      因为成员函数Time::Show()包括一个局部变量和一个for循环，所以编译器一般拒绝inline，并且把它当作一个普通的成员函数。但是这个包含类声明的头文件会被单独的#include进各个独立的编译单元中：    // filename f1.cpp #include "Time.h" void f1() { Time t1; t1.Show(); } // filename f2.cpp #include "Time.h" void f2() { Time t2; t2.Show(); }    结果编译器为这个程序生成了两个相同成员函数的拷贝：    void f1(); void f2(); int main() { f1(); f2(); return 0; }         当程序被链接的时候，linker将会面对两个相同的Time::Show()拷贝，于是函数重定义的连接错误发生。但是老一些的C++实现对付这种情况的办法是通过把一个un-inlined函数当作static来处理。因此每一份函数拷贝仅仅在自己的编译单元中可见，这样链接错误就解决了，但是在程序中却会留下多份函数拷贝。在这种情况下，程序的性能不但没有提升，反而增加了编译和链接时间以及最终可执行体的大小。但是幸运的是，新的C++标准中关于un-inlined函数的说法已经改变。一个符合标准C++实现应该只生成一份函数拷贝。然而，要想所有的编译器都支持这一点可能还需要很长时间。      另外关于内联函数还有两个更令人头疼的问题。第一个问题是该如何进行维护。一个函数开始的时候可能以内联的形式出现，但是随着系统的扩展，函数体可能要求添加额外的功能，结果内联函数就变得不太可能，因此需要把inline   specifier去除以及把函数体放到一个单独的源文件中。另一个问题是当内联函数被应用在代码库的时候产生。当内联函数改变的时候，用户必须重新编译他们的代码以反映这种改变。然而对于一个非内联函数，用户仅仅需要重新链接就可以了。         这里想要说的是，内联函数并不是一个增强性能的灵丹妙药。只有当函数非常短小的时候它才能得到我们想要的效果，但是如果函数并不是很短而且在很多地方都被调用的话，那么将会使得可执行体的体积增大。最令人烦恼的还是当编译器拒绝内联的时候。在老的实现中，结果很不尽人意，虽然在新的实现中有很大的改善，但是仍然还是不那么完善的。一些编译器能够足够的聪明来指出哪些函数可以内联哪些不能，但是，大多数编译器就不那么聪明了，因此这就需要我们的经验来判断。如果内联函数不能增强行能，就避免使用它！   内联和宏的比较 1.预处理器在宏替换时易产生边际效应，导致意想不到的后果； 2.宏不能调试，内联函数可以； 3.宏无法操纵类的私有成员； 4.内联函数的另外一个优点是，函数被内联后，编译器可以根据上下文对代码做进一步优化。这种技术普通函数是做不到的，因为一旦进入普通函数体内就会脱离调用函数的上下文。

本节书摘来自异步社区出版社《C和C++代码精粹》一书中的第1章，第1.19节，作者： 【美】Chuck Allison，更多章节内容可以访问云栖社区“异步社区”公众号查看。 1.19　小结 C和C++代码精粹作为一种多范例式的语言，C++： 1．是更好的C； 2．支持数据抽象； 3．支持面向对象编程。 C++是类型安全语言。 所有函数在第一次使用之前必须声明或定义。引用参数直接支持引用调用语义。可以重载函数和运算符。模板允许创建通用函数。内联函数将类似于函数的宏的高效与实际函数的安全性相结合。自由存储运算符new和delete能根据类型计算对象的大小。声明可以出现在函数可以出现的任意位置。本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。

我们曾经在讨论C++的时候，经常会问到：“虚函数能被声明为内联吗？”现在，我们几乎听不到这个问题了。现在听到的是：“你不应该使print成为内联的。声明一个虚函数为内联是错误的！” 　　这种说法的两个主要的原因是（1）虚函数是在运行期决议而内联是一个编译期动作，所以，我们将虚函数声明为内联并得不到什么效果；（2）声明一个虚函数为内联导致了函数的多分拷贝，而且我们为一个不应该在任何时候内联的函数白白花费了存储空间。这样做很没脑子。 　　不过，事实并不是这样。我们先来看看第一个：许多情况下，虚拟函数都被静态地决议了——比如在派生类虚拟函数中调用基类的虚拟函数的时候。为什么这样做呢？封装。一个比较明显的例子就是派生类析构函数调用链。所有的虚析构函数，除了最初触发这个析构链的虚析构函数，都被静态的决议了。如果不将基类的虚析构函数内联，我们无法从中获利[a]。这和不内联一个虚拟析构函数有什么不同吗？如果继承体系层次比较深并且有许多这样的类的实例要被销毁的话，答案是肯定的。 　　再来看另外一个不用析构函数的例子，想象一下设计一个图书馆类。我们将MaterialLocation作为抽象类LibraryMaterial的一个成员。将它的print成员函数声明为一个纯虚函数，并且提供函数定义：它输出MaterialLocation。 　　class LibraryMaterial      {     　            private: 　　     MaterialLocation _loc; // shared data 　　// … 　　     public: 　　// declares pure virtual function 　     　inline virtual void print(ostream& = cout) = 0;      }; 　　// we actually want to encapsulate the handling of the 　　// location of the material within a base class 　　// LibraryMaterial print（） method - we just don’t want it 　　// invoked through the virtual interface. That is, it is 　　// only to be invoked within a derived class print（） method 　　inline void 　　LibraryMaterial:: 　　print(ostream &os)      {           os <<_loc;      } 　　接着，我们引入一个Book类，它的print函数输出Title, Author等等。在这之前，它调用基类的print函数（LibraryMaterial::print（））来显示书本位置（MaterialLocation）。如下： 　　inline void 　　Book:: 　　print(ostream &os) 　　{ 　　// ok, this is resolved statically, 　　// and therefore is inline expanded … 　      　LibraryMaterial::print()； 　      　os  << "title:"  << _title 　      　<< "author" << _author << endl; 　　} 　　AudioBook类，派生于Book类，并加入附加信息，比如旁述，音频格式等等。这些东西都用它的print函数输出。再这之前，我们需要调用Book::print（）来显示前面的信息。 　　inline void 　　AudioBook:: 　　print(ostream &os) 　　{ 　　// ok, this is resolved statically, 　　// and therefore is inline expanded … 　        　Book::print(); 　　        os <<"narrator:"<< _narrator <<endl; 　　} 　　这和虚析构函数调用链的例子一样，都只是最初调用的虚函数没有被静态决议，其它的都被原地展开。This unnamed hierarchical design pattern is significantly less effective if we never declare a virtual function to be inline. 　　那么对于第二个原因中代码膨胀的问题呢？我们来分析一下，如果我们写下： 　　LibraryMaterial *p = 　　new AudioBook("Mason & Dixon", 　　"Thomas Pynchon", "Johnny Depp"); 　　// … 　　p->print()； 　　这个print实例是内联的吗？不，当然不是。这样不得不通过虚拟机制在运行期决议。这让print实例放弃了对它的内联声明了吗？也不是。这个调用转换为下面的形式（伪代码）： 　　// Pseudo C++ Code 　　// Possible transformation of p->print（） 　　(*p->_vptr[ 2 ])(p); 　　where 2 represents the location of print within the associated virtual function table.因为调用print是通过函数指针_vptr[2]进行的，所以，编译器不能静态的决定这个调用地址，并且，这个函数也不能内联。 　　当然，虚函数print的内联实体（definition）也必须在某个地方表现出来。 即是说，至少有一个函数实体是在virtual table调用的地址原地展开的。编译器是如何决定在何时展开这个函数实体呢？其中一个编译（implementaion）策略是当virtual table生成的同时，生成这个函数实体。这就是说对于每一个派生类的virtual table都会生成一个函数实体。 　　在一个可应用的类[b]中有多少vitrual table会被生成呢？呵呵，这是一个好问题。C++标准中对虚函数行为进行了规定，但是没有对函数实现进行规定。由于virtual table没有在C++标准中进行规定，很明显，究竟这个virtual table怎样生成，和究竟要生成多少个vitrual table也没有规定。多少个？当然，我们只要一个。Stroustrup的cfront编译器，很巧妙的处理了这些情况。（ Stan and Andy Koenig described the algorithm in the March 1990 C++ Report article, "Optimizing Virtual Tables in C++ Release 2.0."） 　　Moreover, the C++ Standard now requires that inline functions behave as though only one definition for an inline function exists in the program even though the function may be defined in different files。新的规则要求编译器只展开一个内联虚函数。如果一点被广泛采用的话，虚函数的内联导致的代码膨胀问题就会消失。

（一）inline函数（摘自C++ Primer的第三版） 在函数声明或定义中函数返回类型前加上关键字inline即把min（）指定为内联。       inline int min(int first, int secend) {/****/};       inline 函数对编译器而言必须是可见的，以便它能够在调用点内展开该函数。与非inline函数不同的是，inline函数必须在调用该函数的每个文本文件中定义。当然，对于同一程序的不同文件，如果inline函数出现的话，其定义必须相同。对于由两个文件compute.C和draw.C构成的程序来说，程序员不能定义这样的min()函数，它在compute.C中指一件事情，而在draw.C中指另外一件事情。如果两个定义不相同，程序将会有未定义的行为：       为保证不会发生这样的事情，建议把inline函数的定义放到头文件中。在每个调用该inline函数的文件中包含该头文件。这种方法保证对每个inline函数只有一个定义，且程序员无需复制代码，并且不可能在程序的生命期中引起无意的不匹配的事情。 （二）内联函数的编程风格(摘自高质量C++/C 编程指南) 关键字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){}  慎用内联 内联能提高函数的执行效率，为什么不把所有的函数都定义成内联函数？如果所有的函数都是内联函数，还用得着“内联”这个关键字吗？内联是以代码膨胀（复制）为代价，仅仅省去了函数调用的开销，从而提高函数的执行效率。如果执行函数体内代码的时间，相比于函数调用的开销较大，那么效率的收获会很少。另一方面，每一处内联函数的调用都要复制代码，将使程序的总代码量增大，消耗更多的内存空间。 以下情况不宜使用内联： （1）如果函数体内的代码比较长，使用内联将导致内存消耗代价较高。 （2）如果函数体内出现循环，那么执行函数体内代码的时间要比函数调用的开销大。类的构造函数和析构函数容易让人误解成使用内联更有效。要当心构造函数和析构函数可能会隐藏一些行为，如“偷偷地”执行了基类或成员对象的构造函数和析构函数。所以不要随便地将构造函数和析构函数的定义体放在类声明中。一个好的编译器将会根据函数的定义体，自动地取消不值得的内联（这进一步说明了 inline 不应该出现在函数的声明中）。 注意点: 内联函数既能够去除函数调用所带来的效率负担又能够保留一般函数的优点。然而，内联函数并不是万能药，在一些情况下，它甚至能够降低程序的性能。因此在使用的时候应该慎重。        1．我们先来看看内联函数给我们带来的好处：从一个用户的角度来看，内联函数看起来和普通函数一样， 它可以有参数和返回值，也可以有自己的作用域，然而它却不会引入一般函数调用所带来的负担。另外， 它可以比宏更安全更容易调试。       当然有一点应该意识到，inline   specifier仅仅是对编译器的建议，编译器有权利忽略这个建议。那么编译器是如何决定函数内联与否呢？一般情况下关键性因素包括函数体的大小，是否有局部对象被声明，函数的复杂性等等。        2．那么如果一个函数被声明为inline但是却没有被内联将会发生什么呢？理论上，当编译器拒绝内联一个   函数的时候，那个函数会像普通函数一样被对待，但是还会出现一些其他的问题。例如下面这段代码：     //   filename   Time.h     #include<ctime>     #include<iostream>     using   namespace   std;     class   Time     {     public:             inline   void   Show()             {                 for (int   i   =   0;   i<10;   i++)                  cout<<time(0)<<endl;          }     };        因为成员函数Time::Show()包括一个局部变量和一个for循环，所以编译器一般拒绝inline，并且把它当作一个普通的成员函数。但是这个包含类声明的头文件会被单独的#include进各个独立的编译单元中：     //   filename   f1.cpp     #include   "Time.h"     void   f1()     {             Time   t1;             t1.Show();     }     //   filename   f2.cpp     #include   "Time.h"     void   f2()     {             Time   t2;             t2.Show();     }     结果编译器为这个程序生成了两个相同成员函数的拷贝：     void   f1();     void   f2();     int   main()     {             f1();               f2();             return   0;     }        当程序被链接的时候，linker将会面对两个相同的Time::Show()拷贝，于是函数重定义的连接错误发生。但是老一些的C++实现对付这种情况的办法是通过把一个un-inlined函数当作static来处理。因此每一份函数拷贝仅仅在自己的编译单元中可见，这样链接错误就解决了，但是在程序中却会留下多份函数拷贝。在这种情况下，程序的性能不但没有提升，反而增加了编译和链接时间以及最终可执行体的大小。但是幸运的是，新的C++标准中关于un-inlined函数的说法已经改变。一个符合标准C++实现应该只生成一份函数拷贝。然而，要想所有的编译器都支持这一点可能还需要很长时间。        另外关于内联函数还有两个更令人头疼的问题。第一个问题是该如何进行维护。一个函数开始的时候可能以内联的形式出现，但是随着系统的扩展，函数体可能要求添加额外的功能，结果内联函数就变得不太可能，因此需要把inline   specifier去除以及把函数体放到一个单独的源文件中。另一个问题是当内联函数被应用在代码库的时候产生。当内联函数改变的时候，用户必须重新编译他们的代码以反映这种改变。然而对于一个非内联函数，用户仅仅需要重新链接就可以了。        这里想要说的是，内联函数并不是一个增强性能的灵丹妙药。只有当函数非常短小的时候它才能得到我们想要的效果，但是如果函数并不是很短而且在很多地方都被调用的话，那么将会使得可执行体的体积增大。最令人烦恼的还是当编译器拒绝内联的时候。在老的实现中，结果很不尽人意，虽然在新的实现中有很大的改善，但是仍然还是不那么完善的。一些编译器能够足够的聪明来指出哪些函数可以内联哪些不能，但是，大多数编译器就不那么聪明了，因此这就需要我们的经验来判断。如果内联函数不能增强行能，就避免使用它！