关于MFC消息宏的疑问，问题不在消息宏本身，而是在宏。

Question

首先声明我是来砸场子的，呵呵好久好久没玩VC++了，一直对MFC没有深入了解耿耿于怀，这些天抽空重新捡起来研究了一下
为了避免使用虚函数带来大的开销，消息处理是使用宏来进行消息映射处理
每增加一个(消息宏 + 消息处理函数)完成一个消息处理，当然消息宏不是随便加的，因为有可能控件根本与某些消息无关。Delphi-VCL 是这样做的，在管理器里每个控件都有一个消息处理列表，在对应的消息处填上你的消息处理函数即可
实际过程是delphi有一个类似virtual的dynamic形式的方法的处理，将函数都编号(消息编号)放在父类的DMT表里，具体过程还不是特别的清楚
在TWinControl这个类里可以看到所有消息处理函数声明，消息路由和MFC的貌似也差不多。所以在delphi里你是看不到消息宏声明的，只有消息处理函数，在管理器里可以查询其对应关系。结论：
MFC消息处理大量使用宏这个东西，我觉得好原始，不好管理，不易调试，学习起来也增加了难度。你们觉得宏这个东西是好东西吗？是C++语言的局限性还是一些人装比故弄玄虚呢。欢迎拍砖(说不定还有我的同学在内)，手下留情，嘿嘿PS:仅限于VC++6

Answer 1

那些东西据说是MFC刚刚诞生的时候的设计，虽然后来认识到其不足，但是积重难返，修改的话，代价太大了。而且后来微软的重心转向.net，对MFC只是修修补补，不太可能有大的进化了吧。
Delphi诞生的时候已经有很成熟的榜样了，比如微软的VB等等，也能避免很多前人走过的弯路，比如MFC；所以如果因此来下结论说MFC多原始Delphi多先进的，就有些忘本了。而MFC这方面，似乎也没有什么有名望的人物出来称颂它多么多么的优美多么多么的先进，所以不知道楼主为何会突然生出这么多胜负优劣之心的。

Answer 2

确实，虚函数可以用做到和Delphi/VCL类似的功能，就是建立所有虚函数的消息表，然后用户只需要填充消息响应函数的表即可；正如你所说，一方面这增加了虚函数的开销，另一方面，随着操作系统的进化增加的新的消息和修改消息参数都变得复杂了，作为底层开发工具不见得就有优势。要说起来，动态语言（比如脚本）在事件方面更加灵活，但是调用的代价也更大。只能说，MFC的消息机制，既是历史原因，也有现实原因。

Answer 3

机器越来越快, 程序运行速度不是关键, 开发速度才是重点, 高级语言应用更广C算不上高级语言, 算是一种中级语言, 
VC也类似, 框架相对比较简单, 所以方便性不太好"MFC消息处理大量使用宏这个东西，我觉得好原始，不好管理，不易调试，学习起来也增加了难度。"
相对初学来说可能是这样子, 但是如果自己看懂框架更助于熟悉消息机制
像Delphi 之类的经常遇到奇怪的问题, 怎么都找不到原因, 框架太大会有这个问题
一个东西的存在总有他的理由, 仁者见仁,智者见智

Answer 4

耿耿于怀啊，MFC太难学了，VC-IDE设计者本意可能是想让程序员避开一些东西简化开发过程，而实际上却没有做到！
与Delphi比较无非是有个参照物，发表一下个人的观点而已，讨论孰优孰劣其实意义不大，这主要看应用的场合。我的意思是： 遇上这种类似窗口-消息处理的情况我们还会这么做吗，应该如何重新设计呢？

Answer 5

zzz3265 说得比 Mackz(4楼) 更好，Delphi的确存在一些Bug很难找出原因来，哈
Delphi在消息处理没有使用virtual 其实和MFC相比在思想上有相似之处的

Answer 6

消息处理机制貌似不止是vc独有的，好像是从更老资格的Borland C++学来的.
因为历史原因,肯定是不完美的.这也是qt独创了信号--槽机制的原因
MFC中的消息机制没有采用C++中的虚函数机制,原因是消息太多,虚函数开销太大.在Qt中也没有采用C++中的虚函数机制,原因与此相同.其实这里还有更深层次上的原因,大体说来,
多态的底层实现机制只有两种,一种是按照名称查表,一种是按照位置查表,两种方式各有利弊,而C++的虚函数机制无条件的采用了后者,导致的问题就是在子类很少重载基类实现
的时候开销太大,再加上象界面编程这样子类众多的情况,基本上C++的虚函数机制就废掉了,于是各家库的编写者就只好自谋生路了,说到底,这确实是C++语言本身的缺陷

Answer 7

有一句话我赞成：MFC是上手容易（因为有IDE的各种向导帮忙），但是要精通MFC比精通SDK编程还难。框架原理、消息路由都要完全掌握才能更进一步。有空学习ATL/WTL，代码中的宏跟MFC很相似，但是原理完全不同，做出来的程序比SDK编的程序稍稍大一点，但是不依赖任何支持库，性能和灵活性比MFC高很多。当然下一代该学习WPF了。