深入浅出MFC对于虚函数实现方式的缺点，它指出：虚函数耗费大量内存，系统最终将被这些额外负担拖垮。
但是现在对于容量巨大的白菜价格的内存来说，这种额外负担是否已经过时了呢~？
书中提到，虚函数表中的每一个项目都是一个函数指针，价值4字节，如果基类的虚函数表有100项 （MFC里面的消息数量是否在这个数量级？），经过十层继承，开支散叶，总共需要耗费多少内存？
我粗略地算了下，不知道这种计算方法是否正确，4Byte*100项=400Byte。如果CCmdTarget中定义100个消息，那其中虚函数表字段大约要占用400字节的内存。
然后我数了下，MFC中派生自CCmdTarget的类总共有100个，那么这么多类的虚函数表总共需要占用多少个字节呢？
400Byte*100个=40KB字节。
然后加上 程序员自己派生的类和消息 所多占的函数指针项，我想也应该不会超过40KB这个基础内存空间的10倍吧？也就是不超过400KB字节的内存。
然而现在动辄几G的内存，这点消耗大概应该可以忽略不计吧？
所以，我的问题是，如果如书上所说，虚函数的实现方案增加了太多的额外负担，那我以上的计算方法哪里出错了？
如果我的上述讨论方法正确的话，那是否能说明书上的说法已经过时，而利用虚函数的实现方法，用空间换取执行效率上的提高可行呢？
使用消息映射表将会为每个类产生一个map，包含本类感兴趣的那些消息，占用内存可想而知比先前使用虚函数的方法要小很多，但是迭代的搜寻操会比直接调用虚函数的效率要低。
《深入浅入MFC》侯捷老师当时的硬件环境，书中说到“16MB的内存会让机器工作更舒适”，而他本人所使用的内存是96MB。
而虚函数所带来的额外内存占用应该是 百K级别到M级别。相对于不足100M的内存容量来说确实是巨大的数字。因此，在那个年代，虚函数的实现确实是代价巨大。
然而到了2009年的今天，深入浅出MFC上仍然说虚函数带来巨大的额外负担，应该是有点言过其实了。因为1M以上的消耗对于占用的内存比例应该是绝大部分人能够负担的了。
而使用虚函数方式实现消息映射，可以提高程序运行的效率。
MFC消息映射是宏实现, 占用的是编译时, 毫不影响运行时 ，错误，确实是编译时，这个宏依然是 需要进行函数调用的，而且这个调用是迭代的，他的运行时开销只会比虚函数大，不会小。
在当时限于硬件环境所迫，MS才考虑到牺牲时间来换取空间上的效率，所以这种设计方式在当时确实是起到很大作用的。
但是随着时代的发展，硬件的极大改善，这种方法带来的影响越来越小。但是微软不能从底层上改变设计的思路吧？因为他毕竟要考虑到兼容性问题。而且推翻 WINDOWS 引以为傲的最基本的消息映射表的实现方式，重新开发的成本应该会很高。
但是现在硬件提升的不仅仅只有内存，还有CPU等其他设备，所以消息映射表对于运行时的效率降低也可以忽略不计的。这也应该就是MS没有花大代价去改造WINDOWS系统地原因。