深入浅出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系统地原因。
标签：MFC,函数,映射,消息,内存,100,表和虚 来源： https://blog.csdn.net/qq_41607336/article/details/121207978
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。