在类中如何定义内联成员函数（什么是内联函数为什么要引入内联函数使用内联函数应该注意什么事情）

本文目录

• 什么是内联函数为什么要引入内联函数使用内联函数应该注意什么事情
• C++标准编程：虚函数与内联
• C++中内联函数有什么用处，具体该怎么用
• 对于C++中，class的类的小问题
• 类的成员函数的定义位置

什么是内联函数为什么要引入内联函数使用内联函数应该注意什么事情

内联函数 在类声明的内部声明或定义的成员函数叫做内联（INLINE)函数.
有两种实现方式：
1.在类声明的内部声明，而在类声明外部定义叫做显式内联函数，如：
class display
{
int t;
public:
void output(void)
}
display object;
inline void display::output(void)
{
cout 《《 "i is " 《《 i 《《"\n";
}
2.在类声明的内部定义，叫做隐式内联函数，如：
class display
{
int t;
public:
inline void output(void)
{cout《《"i is "《《 i 《《 "\n";}
}
引入内联函数的目的是为了解决程序中函数调用的效率问题。
函数是一种更高级的抽象。它的引入使得编程者只关心函数的功能和使用方法，而不必关心函数功能的具体实现；函数的引入可以减少程序的目标代码，实现程序代码和数据的共享。但是，函数调用也会带来降低效率的问题，因为调用函数实际上将程序执行顺序转移到函数所存放在内存中某个地址，将函数的程序内容执行完后，再返回到转去执行该函数前的地方。这种转移操作要求在转去前要保护现场并记忆执行的地址，转回后先要恢复现场，并按原来保存地址继续执行。因此，函数调用要有一定的时间和空间方面的开销，于是将影响其效率。特别是对于一些函数体代码不是很大，但又频繁地被调用的函数来讲，解决其效率问题更为重要。引入内联函数实际上就是为了解决这一问题。
在程序编译时，编译器将程序中出现的内联函数的调用表达式用内联函数的函数体来进行替换。显然，这种做法不会产生转去转回的问题，但是由于在编译时将函数体中的代码被替代到程序中，因此会增加目标程序代码量，进而增加空间开销，而在时间代销上不象函数调用时那么大，可见它是以目标代码的增加为代价来换取时间的节省。
在程序中，调用其函数时，该函数在编译时被替代，而不是像一般函数那样是在运行时被调用。
使用内联函数应注意的事项
内联函数具有一般函数的特性，它与一般函数所不同之处只在于函数调用的处理。一般函数进行调用时，要将程序执行权转到被调用函数中，然后再返回到调用它的函数中；而内联函数在调用时，是将调用表达式用内联函数体来替换。在使用内联函数时，应注意如下几点：
1.在内联函数内不允许用循环语句和开关语句。
如果内联函数有这些语句，则编译将该函数视同普通函数那样产生函数调用代码,递归函数(自己调用自己的函数)是不能被用来做内联函数的。内联函数只适合于只有1～5行的小函数。对一个含有许多语句的大函数，函数调用和返回的开销相对来说微不足道，所以也没有必要用内联函数实现。
2.内联函数的定义必须出现在内联函数第一次被调用之前。
3.本栏目讲到的类结构中所有在类说明内部定义的函数是内联函数。

C++标准编程：虚函数与内联

我们曾经在讨论C++的时候，经常会问到：“虚函数能被声明为内联吗？”现在，我们几乎听不到这个问题了。现在听到的是：“你不应该使print成为内联的。声明一个虚函数为内联是错误的！”
这种说法的两个主要的原因是（1）虚函数是在运行期决议而内联是一个编译期动作，所以，我们将虚函数声明为内联并得不到什么效果；（2）声明一个虚函数为内联导致了函数的多分拷贝，而且我们为一个不应该在任何时候内联的函数白白花费了存储空间。这样做很没脑子。
不过，事实并不是这样。我们先来看看第一个：许多情况下，虚拟函数都被静态地决议了——比如在派生类虚拟函数中调用基类的虚拟函数的时候。为什么这样做呢？封装。一个比较明显的例子就是派生类析构函数调用链。所有的虚析构函数，除了最初触发这个析构链的虚析构函数，都被静态的决议了。如果不将基类的虚析构函数内联，我们无法从中获利。这和不内联一个虚拟析构函数有什么不同吗？如果继承体系层次比较深并且有许多这样的类的实例要被销毁的话，答案是肯定的。
再来看另外一个不用析构函数的例子，想象一下设计一个图书馆类。我们将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 ）（ p ）；
where 2 represents the location of print within the associated virtual function table.因为调用print是通过函数指针_vptr进行的，所以，编译器不能静态的决定这个调用地址，并且，这个函数也不能内联。
当然，虚函数print的内联实体（definition）也必须在某个地方表现出来。 即是说，至少有一个函数实体是在virtual table调用的地址原地展开的。编译器是如何决定在何时展开这个函数实体呢？其中一个编译（implementaion）策略是当virtual table生成的同时，生成这个函数实体。这就是说对于每一个派生类的virtual table都会生成一个函数实体。
在一个可应用的类中有多少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。新的规则要求编译器只展开一个内联虚函数。如果一点被广泛采用的话，虚函数的内联导致的代码膨胀问题就会消失。
============================
译注：
函数调用开销，调用基类虚函数的时候至少要经过两次间接过程（S. B.Lippman: 《Inside the C++ Object Model》）
一个产品类（？）
总结：
就是虚函数inline在调用链等地方很有用~
即使没有加入inline声明，作为一个好编译器，都会优化（虚析构函数）
在很长的函数调用链中，最好将链中基类的函数inline，这样节约开销
至于在什么地方inline，由编译器决定，因为C++标准没有规定
新C++标准（可能没有通过）中，规定了，inline化只对产品类有效，且只动作一次
保证代码不过度膨胀
inline动作是在产品类实例化同时，和vtable生成一起。

C++中内联函数有什么用处，具体该怎么用

内联函数必须是和函数体申明在一起，才有效。像这样的申明Inline Tablefunction(int I)是没有效果的，编译器只是把函数作为普通的函数申明，我们必须定义函数体。
Inline tablefunction(int I) {return I*I};
　　这样我们才算定义了一个内联函数。我们可以把它作为一般的函数一样调用。但是执行速度确比一般函数的执行速度要快。
　　我们也可以将定义在类的外部的函数定义为内联函数，比如：
Class TableClass{
　Private:
　　Int I,j;
　Public:
　　Int add() { return I+j;};
　　Inline int dec() { return I-j;}
　　Int GetNum();
}
inline int tableclass::GetNum(){
return I;
}
　　上面申明的三个函数都是内联函数。在C++中，在类的内部定义了函数体的函数，被默认为是内联函数。而不管你是否有inline关键字。
　　内联函数在C++类中，应用最广的，应该是用来定义存取函数。我们定义的类中一般会把数据成员定义成私有的或者保护的，这样，外界就不能直接读写我们类成员的数据了。对于私有或者保护成员的读写就必须使用成员接口函数来进行。如果我们把这些读写成员函数定义成内联函数的话，将会获得比较好的效率。
Class sample{
　Private:
　　Int nTest;
　Public:
　　Int readtest(){ return nTest;}
　Void settest(int I) {nTest=I;}
}
　　当然，内联函数也有一定的局限性。就是函数中的执行代码不能太多了，如果，内联函数的函数体过大，一般的编译器会放弃内联方式，而采用普通的方式调用函数。这样，内联函数就和普通函数执行效率一样了。

对于C++中，class的类的小问题

如果在类里面定义为内联函数。或者函数实现体虽然在类外，但是都在.h文件中的话，关键字inline是声明为内联函数。 代码量只有一行的函数可以声明为内联函数，内联函数和其他成员函数的区别就是内联函数在编译的时候就把实现体加载进去了，而其他的成员函数就是调用的时候动态添加。一般为了统一风格，吧类的定义放在.h文件，实现放在.cpp文件 比如Car类， 定义放在car.h文件，实现房子啊car.cpp文件

类的成员函数的定义位置

加分号;的成员函数是在类里边定义,实现在类外.
不加的,实现和定义都在类里边完成...
在类里边定义实现的(即不加的)就相当于内联函数inline,调用时程序不跳转,就是用这整块代码替代.不是内联的就要调用函数.保存现场.内联的好处是可以加快程序的效率.不过要消耗很多空间.具体的要根据:
如果是赋值,if else这样的简单函数就内联,其他的有递归的,函数调用的一般不内联.