MFC为何使用消息映射表而不是虚函数？
这个问题是windows开发面试中最经常问到得问题，也是很有深度的一个问题。
有两个帖子对该问题讨论的比较深刻：
http://topic.csdn.net/u/20090822/16/4cf5d189-0e5e-41ff-9ba3-c7eaf2f6da74.html
http://topic.csdn.net/u/20090316/22/8b067591-6a17-4970-b224-41ab589294b3.html
说法一：
虚函数实现占用内存较大
侯捷在《深入浅出MFC》中说微软使用消息映射机制而不用虚函数，是因为虚函数空间代价的原因。在当前MFC2.0版本发布的时候是92年，pc的内存才几M。一个类的虚表的大小就是虚函数的个数*一个指针的大小。
假设windows的通用消息有200个，那么CWnd类的虚表就有 200*4个byte = 800byte
CWnd类的所有派生类均copy了一份CWnd的虚表vtable，然后自己的虚函数往后加CWnd类的虚表的后头。
（至于有人说CWnd类的派生类能共享CWnd的虚表，这个说法不靠谱。因为派生类自己的虚函数值加在基类的虚函数表项的最后的。如果CWnd派生了CWndChildA 和 CWndChildB，且两个孩子均有自己的虚函数，那么都往CWnd类的后面加，岂不是冲突了？）
也就是系统内所有的CWnd类的派生类都要承受 800byte的代价。假设有100个类派生自CWnd 那么代价就是800*100byte 也就是 80K。这在当时内存很紧张的情况下，已经是一种巨大的内存消耗了！这里需要注意一点：vtable是和类绑定在一起的，而不是和类对象（也叫类的实例）绑定在一起的，类的实例仅增加一个指向该向类的vtable的指针而已。也就是说，如果你有100个CWnd派生类，哪怕你生成了100000个派生类的实例，vtable占用的内存也是80K。
看来在当时的环境看来，MFC没有采用虚函数，内存的确是一个考虑。
但是放在现在看，这点内存消耗确实微不足道的！ 也就是说，如果现在重新设计MFC的消息机制，如果不采用虚函数，并非因为虚函数的空间浪费问题。
结论：这个说法靠谱。
说法二：
消息映射机制效率比虚函数效率高。
因为那么多消息ID，如果找到其对应的消息处理函数，switch是不可少的！（可以hash？哦哦，的确可能，不过mfc里面可没这么做？mfc里面怎么做的我也不清楚）
MFC中采用的是消息映射的机制，而没有用虚函数的机制，因为消息有很多，如果用虚函数机制，需要给每个消息定义一个虚函数，在分派消息时，程序需要逐一判断是哪一个消息，找到合适的分支后再调用相应的虚函数；而通常情况下，应用程序不需要响应太多的消息，消息映射方式只需要判断程序想要响应的这些消息即可，所以开销小。
也就是说，MFC采用了消息映射而没有采用虚函数，是从对消息的响应机制来考虑的。 消息映射，就可以仅实现自己感兴趣的消息，这样switch时就可以快一点。
不过话又说回来，对一个非自己感兴趣的系统消息来了以后，就需要遍历消息网，层层的向基类查找直到找到对应的消息处理函数！这本身也很浪费时间！也许这种情况比较少见吧，否则的话，消息映射的消息响应时间并不比虚函数来的快！因为虚函数最多只需一次遍历，而且，如果可以采用hash技术，更快！
如果说，大多数消息都是系统的消息，那么消息映射的迭代查找消息函数的方式并不比虚函数的switch来的快！
PS：这里有一篇对比消息映射机制和虚函数机制效率的简单模拟实验
http://blog.csdn.net/hjsunj/archive/2008/01/10/2034314.aspx
结论，该说法不靠谱！
说法三：
为了未来的可扩展性。兼容新的系统级的消息。
我不是很清楚MS设计消息映射的初衷，但是感觉它着眼点更侧重于增加新消息很容易，而不是节省内存。
如果我们使用虚函数机制实现，恐怕对于每个可能的消息我们都必须在基类中定义一个虚函数，而其首要的困难就是你无法猜测未来会出现什么消息，也无法确定需要定义什么样函数原型的虚函数。而使用消息映射，解决这个问题则相对容易，因为这将由未来的程序设计者决定他们的消息该如何处理。
对于系统的新增消息，消息映射支持起来较方便。虚函数想要支持就需要改动基类添加虚函数。
对于自定义的消息，无论消息映射和虚函数都可以很好的支持。
那么虚函数方式如何支持自定义消息?
自定义消息是不需要加到基类的。基类可以加个虚函数，OnMessage(xxx), 然后有自定义消息的类实现之，用switch转换成相应虚函数调用，不是自己的消息再传给基类。
结论：这个说法靠谱。
有两个帖子对该问题讨论的比较深刻：
http://topic.csdn.net/u/20090822/16/4cf5d189-0e5e-41ff-9ba3-c7eaf2f6da74.html
http://topic.csdn.net/u/20090316/22/8b067591-6a17-4970-b224-41ab589294b3.html
说法一：
虚函数实现占用内存较大
侯捷在《深入浅出MFC》中说微软使用消息映射机制而不用虚函数，是因为虚函数空间代价的原因。在当前MFC2.0版本发布的时候是92年，pc的内存才几M。一个类的虚表的大小就是虚函数的个数*一个指针的大小。
假设windows的通用消息有200个，那么CWnd类的虚表就有 200*4个byte = 800byte
CWnd类的所有派生类均copy了一份CWnd的虚表vtable，然后自己的虚函数往后加CWnd类的虚表的后头。
（至于有人说CWnd类的派生类能共享CWnd的虚表，这个说法不靠谱。因为派生类自己的虚函数值加在基类的虚函数表项的最后的。如果CWnd派生了CWndChildA 和 CWndChildB，且两个孩子均有自己的虚函数，那么都往CWnd类的后面加，岂不是冲突了？）
也就是系统内所有的CWnd类的派生类都要承受 800byte的代价。假设有100个类派生自CWnd 那么代价就是800*100byte 也就是 80K。这在当时内存很紧张的情况下，已经是一种巨大的内存消耗了！这里需要注意一点：vtable是和类绑定在一起的，而不是和类对象（也叫类的实例）绑定在一起的，类的实例仅增加一个指向该向类的vtable的指针而已。也就是说，如果你有100个CWnd派生类，哪怕你生成了100000个派生类的实例，vtable占用的内存也是80K。
看来在当时的环境看来，MFC没有采用虚函数，内存的确是一个考虑。
但是放在现在看，这点内存消耗确实微不足道的！ 也就是说，如果现在重新设计MFC的消息机制，如果不采用虚函数，并非因为虚函数的空间浪费问题。
结论：这个说法靠谱。
说法二：
消息映射机制效率比虚函数效率高。
因为那么多消息ID，如果找到其对应的消息处理函数，switch是不可少的！（可以hash？哦哦，的确可能，不过mfc里面可没这么做？mfc里面怎么做的我也不清楚）
MFC中采用的是消息映射的机制，而没有用虚函数的机制，因为消息有很多，如果用虚函数机制，需要给每个消息定义一个虚函数，在分派消息时，程序需要逐一判断是哪一个消息，找到合适的分支后再调用相应的虚函数；而通常情况下，应用程序不需要响应太多的消息，消息映射方式只需要判断程序想要响应的这些消息即可，所以开销小。
也就是说，MFC采用了消息映射而没有采用虚函数，是从对消息的响应机制来考虑的。 消息映射，就可以仅实现自己感兴趣的消息，这样switch时就可以快一点。
不过话又说回来，对一个非自己感兴趣的系统消息来了以后，就需要遍历消息网，层层的向基类查找直到找到对应的消息处理函数！这本身也很浪费时间！也许这种情况比较少见吧，否则的话，消息映射的消息响应时间并不比虚函数来的快！因为虚函数最多只需一次遍历，而且，如果可以采用hash技术，更快！
如果说，大多数消息都是系统的消息，那么消息映射的迭代查找消息函数的方式并不比虚函数的switch来的快！
PS：这里有一篇对比消息映射机制和虚函数机制效率的简单模拟实验
http://blog.csdn.net/hjsunj/archive/2008/01/10/2034314.aspx
结论，该说法不靠谱！
说法三：
为了未来的可扩展性。兼容新的系统级的消息。
我不是很清楚MS设计消息映射的初衷，但是感觉它着眼点更侧重于增加新消息很容易，而不是节省内存。
如果我们使用虚函数机制实现，恐怕对于每个可能的消息我们都必须在基类中定义一个虚函数，而其首要的困难就是你无法猜测未来会出现什么消息，也无法确定需要定义什么样函数原型的虚函数。而使用消息映射，解决这个问题则相对容易，因为这将由未来的程序设计者决定他们的消息该如何处理。
对于系统的新增消息，消息映射支持起来较方便。虚函数想要支持就需要改动基类添加虚函数。
对于自定义的消息，无论消息映射和虚函数都可以很好的支持。
那么虚函数方式如何支持自定义消息?
自定义消息是不需要加到基类的。基类可以加个虚函数，OnMessage(xxx), 然后有自定义消息的类实现之，用switch转换成相应虚函数调用，不是自己的消息再传给基类。
结论：这个说法靠谱。
