关于虚函数那点破事

如果你是C++程序员，我想你可能遇到过这样的情况：

在debug时，对着一个函数step into，明明调用的是A函数，可是结果却跳进了B函数。

为什么，call stack里显示的也是明明白白，就是直接进了B函数。百思不得其解，于是你怀疑是不是系统出了问题，是不是编译器出了问题，是不是调试器出了问题~~~

其实那些玩意不是那么容易出错的，先看看你你的A，B函数是不是同一个类的虚函数，如果是，这极有可能是因为你修改过虚函数而没有完全编译引起的。

还没明白？看看这个例子, 假设你在Project1中有一个名为DebuggingNow的类，该类有三个虚函数：

?

1 2 3 4 5 6 7

class DebuggingNow { public: virtual void f1(); virtual void f2(); virtual void f3(); };

在Project2中你调用了其虚函数：

?

1	pDbgNow->f2();

之后由于某种需求你在这个类中加入了一个虚函数：

?

1 2 3 4 5 6 7 8

class DebuggingNow { public: virtual void f1(); virtual void f1_5(); virtual void f2(); virtual void f3(); };

只编译Project1，在Project2中调用到pDbgNow->f2()时，你就会发现本文一开始描述的情况：明明调用的是f2()，结果却进了f1_5()。理由如下：

pDbgNow->f2()之前被编译为调用类DebuggingNow的第二个虚函数，因为是虚函数，其真正调用类似于pDbgNow->vtable[1]。因为在加入函数f1_5()后，f1_5成为了该虚表中的第二个函数，但由于没有重新编译Project2，pDbgNow->f2()的调用没有更新为正确的pDgbNow->vtable[2]，所以真正调用的是函数f1_5()，与函数名无关。

可能你会认为这种"低级错误"根本不会发生在你身上，至少有两个方法来解决这个问题：

1. 永远把虚函数加到最后
2. 永远编译所有的工程

的确，这两招在一定程度上是有效的，但让我们仔细分析一下：

1. 永远把虚函数加到最后，针对上面这个例子是有用的。可是如果有其他类派生于类DebuggingNow，即使你把虚函数加到了类DebuggingNow的最后，还是会打乱其派生类的虚表。
2. 永远编译所有的工程，这的确是一个保险的方法。可是在一个大型系统中，编译所有的代码所耗费的时间是非常大的，加了一个虚函数，你可能得等上个好几个小时才能看到最后的结果，这是我们不愿承受的。

 

那么，对于大型系统中一个正处于积极修改期的核心基类，一个比较好的操作方法是预先分配好足够多的虚函数，这样之后需要加虚函数是，只要修改一个原有的就行了，无需大规模的rebuild ,只需编译一下用到了这个虚函数的代码就可以了。可以说节省的时间是相当可观的：

?

1 2 3 4 5 6 7 8 9 10 11 12

class DebuggingNow { public: virtual void f1(); virtual void f2(); virtual void f3(); virtual void dummyvirtualfunction1(); virtual void dummyvirtualfunction2(); virtual void dummyvirtualfunction3(); virtual void dummyvirtualfunction5(); virtual void dummyvirtualfunction6(); };

 

只要灵活运用dummyvirtualfunction，你不光可以运用于加虚函数，也可以在删虚函数时发挥其作用。

记住两个操作原则：

1. 当dummyvirtualfunction快用完时，再预先分配一些。
2. 当这一阶段开发结束时，该基类趋于稳定，把多余的dummyvirtualfunction去掉就可以了。