添加删除虚函数带来的问题及解决办法
转载整理自：关于虚函数那点破事
问题：
如果你是C++程序员，我想你可能遇到过这样的情况：
在debug时，对着一个函数step into，明明调用的是A函数，可是结果却跳进了B函数。
为什么，call stack里显示的也是明明白白，就是直接进了B函数。百思不得其解，于是你怀疑是不是系统出了问题，是不是编译器出了问题，是不是调试器出了问题~~~
其实那些玩意不是那么容易出错的，先看看你你的A，B函数是不是同一个类的虚函数，如果是，这极有可能是因为你修改过虚函数而没有完全编译引起的。
还没明白？看看这个例子, 假设你在Project1中有一个名为DebuggingNow的类，该类有三个虚函数：
在Project2中你调用了其虚函数：
之后由于某种需求你在这个类中加入了一个虚函数：
1 | class DebuggingNow |
2 | { |
3 | public: |
4 | virtual void f1(); |
5 | virtual void f1_5(); |
6 | virtual void f2(); |
7 | virtual void f3(); |
8 | }; |
只编译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()，与函数名无关。
解决办法：
可能你会认为这种"低级错误"根本不会发生在你身上，至少有两个方法来解决这个问题：
- 永远把虚函数加到最后
- 永远编译所有的工程
的确，这两招在一定程度上是有效的，但让我们仔细分析一下：
- 永远把虚函数加到最后，针对上面这个例子是有用的。可是如果有其他类派生于类DebuggingNow，即使你把虚函数加到了类DebuggingNow的最后，还是会打乱其派生类的虚表。
- 永远编译所有的工程，这的确是一个保险的方法。可是在一个大型系统中，编译所有的代码所耗费的时间是非常大的，加了一个虚函数，你可能得等上个好几个小时才能看到最后的结果，这是我们不愿承受的。
那么，对于大型系统中一个正处于积极修改期的核心基类，一个比较好的操作方法是预先分配好足够多的虚函数，这样之后需要加虚函数时，只要修改一个原有的就行了，无需大规模的rebuild ,只需编译一下用到了这个虚函数的代码就可以了。可以说节省的时间是相当可观的：
01 | class DebuggingNow |
02 | { |
03 | public: |
04 | virtual void f1(); |
05 | virtual void f2(); |
06 | virtual void f3(); |
07 | virtual void dummyvirtualfunction1(); |
08 | virtual void dummyvirtualfunction2(); |
09 | virtual void dummyvirtualfunction3(); |
10 | virtual void dummyvirtualfunction5(); |
11 | virtual void dummyvirtualfunction6(); |
12 | }; |
有了dummyvirtualfunction，加新虚函数，将不再需要编译那些使用老的虚函数的模块。。。减少build时间了！
只要灵活运用dummyvirtualfunction，你不光可以运用于加虚函数，也可以在删虚函数时发挥其作用。
记住两个操作原则：
- 当dummyvirtualfunction快用完时，再预先分配一些。
- 当这一阶段开发结束时，该基类趋于稳定，把多余的dummyvirtualfunction去掉就可以了。
