这个问题是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转换成相应虚函数调用,不是自己的消息再传给基类。
结论:这个说法靠谱。