转载整理自:关于虚函数那点破事
问题:
如果你是C++程序员,我想你可能遇到过这样的情况:
在debug时,对着一个函数step into,明明调用的是A函数,可是结果却跳进了B函数。
为什么,call stack里显示的也是明明白白,就是直接进了B函数。百思不得其解,于是你怀疑是不是系统出了问题,是不是编译器出了问题,是不是调试器出了问题~~~
其实那些玩意不是那么容易出错的,先看看你你的A,B函数是不是同一个类的虚函数,如果是,这极有可能是因为你修改过虚函数而没有完全编译引起的。
还没明白?看看这个例子, 假设你在Project1中有一个名为DebuggingNow的类,该类有三个虚函数:
在Project2中你调用了其虚函数:
之后由于某种需求你在这个类中加入了一个虚函数:
只编译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 ,只需编译一下用到了这个虚函数的代码就可以了。可以说节省的时间是相当可观的:
07 | virtual void dummyvirtualfunction1(); |
08 | virtual void dummyvirtualfunction2(); |
09 | virtual void dummyvirtualfunction3(); |
10 | virtual void dummyvirtualfunction5(); |
11 | virtual void dummyvirtualfunction6(); |
有了dummyvirtualfunction,加新虚函数,将不再需要编译那些使用老的虚函数的模块。。。减少build时间了!
只要灵活运用dummyvirtualfunction,你不光可以运用于加虚函数,也可以在删虚函数时发挥其作用。
记住两个操作原则:
- 当dummyvirtualfunction快用完时,再预先分配一些。
- 当这一阶段开发结束时,该基类趋于稳定,把多余的dummyvirtualfunction去掉就可以了。