您好，C++编译器们必须实现语言的每一个特性。这些实现的细节当然是由编译器来决定的，并且不同的编译器有不同的方法实现语言的特性。在多数情况下，你不用关心这些事情。然而有些特性的实现对对象大小和其成员函数执行速度有很大的影响，所以对于这些特性有一个基本的了解，知道编译器可能在背后做了些什么，就显得很重要。这种特性中最重要的例子是虚拟函数。
当调用一个虚拟函数时，被执行的代码必须与调用函数的对象的动态类型相一致；指向对象的指针或引用的类型是不重要的。编译器如何能够高效地提供这种行为呢？大多数编译器是使用virtual table和virtual table pointers。virtual table和virtual table pointers通常被分别地称为vtbl和vptr。
一个vtbl通常是一个函数指针数组。（一些编译器使用链表来代替数组，但是基本方法是一样的）在程序中的每个类只要声明了虚函数或继承了虚函数，它就有自己的vtbl，并且类中vtbl的项目是指向虚函数实现体的指针。例如，如下这个类定义：
class C1 {
public:
C1();
virtual ~C1();
virtual void f1();
virtual int f2(char c) const;
virtual void f3(const string& s);
void f4() const;
...
};
C1的virtual table数组看起来如下图所示：
注意非虚函数f4不在表中，而且C1的构造函数也不在。非虚函数（包括构造函数，它也被定义为非虚函数）就象普通的C函数那样被实现，所以有关它们的使用在性能上没有特殊的考虑。
如果有一个C2类继承自C1，重新定义了它继承的一些虚函数，并加入了它自己的一些虚函数，
class C2: public C1 {
public:
C2(); // 非虚函数
virtual ~C2(); // 重定义函数
virtual void f1(); // 重定义函数
virtual void f5(char *str); // 新的虚函数
...
};
它的virtual table项目指向与对象相适合的函数。这些项目包括指向没有被C2重定义的C1虚函数的指针：
这个论述引出了虚函数所需的第一个代价：你必须为每个包含虚函数的类的virtual talbe留出空间。类的vtbl的大小与类中声明的虚函数的数量成正比（包括从基类继承的虚函数）。每个类应该只有一个virtual table，所以virtual table所需的空间不会太大，但是如果你有大量的类或者在每个类中有大量的虚函数，你会发现vtbl会占用大量的地址空间。
因为在程序里每个类只需要一个vtbl拷贝，所以编译器肯定会遇到一个棘手的问题：把它放在哪里。大多数程序和程序库由多个object（目标）文件连接而成，但是每个object文件之间是独立的。哪个object文件应该包含给定类的vtbl呢？你可能会认为放在包含main函数的object文件里，但是程序库没有main，而且无论如何包含main的源文件不会涉及很多需要vtbl的类。编译器如何知道它们被要求建立那一个vtbl呢？
必须采取一种不同的方法，编译器厂商为此分成两个阵营。对于提供集成开发环境（包含编译程序和连接程序）的厂商，一种干脆的方法是为每一个可能需要vtbl的object文件生成一个vtbl拷贝。连接程序然后去除重复的拷贝，在最后的可执行文件或程序库里就为每个vtbl保留一个实例。
更普通的设计方法是采用启发式算法来决定哪一个object文件应该包含类的vtbl。通常启发式算法是这样的：要在一个object文件中生成一个类的vtbl，要求该object文件包含该类的第一个非内联、非纯虚拟函数（non-inline non-pure virual function）定义（也就是类的实现体）。因此上述C1类的vtbl将被放置到包含C1::~C1定义的object文件里（不是内联的函数），C2类的vtbl被放置到包含C1::~C2定义的object文件里（不是内联函数）。
实际当中，这种启发式算法效果很好。但是如果你过分喜欢声明虚函数为内联函数（参见Effective C++条款33），如果在类中的所有虚函数都内声明为内联函数，启发式算法就会失败，大多数基于启发式算法的编译器会在每个使用它的object文件中生成一个类的vtbl。在大型系统里，这会导致程序包含同一个类的成百上千个vtbl拷贝！大多数遵循这种启发式算法的编译器会给你一些方法来人工控制vtbl的生成，但是一种更好的解决此问题的方法是避免把虚函数声明为内联函数。下面我们将看到，有一些原因导致现在的编译器一般总是忽略虚函数的的inline指令。
温馨提示：答案为网友推荐，仅供参考