[密技]：有感于MFC库代码之去简就繁、之故弄玄虚

fyje

<p><font color=blue><b><u>本贴已经被斑竹移动到文章中心，加10个爱心币！</u></b></font></p>

1. <table border=1 cellpadding=0 cellspacing=0 style=border-collapse: collapse bordercolor=#111111 width=650 id=AutoNumber1 height=498><tr><td width=100% height=489><iframe name=I1 width=100% height=100% src=/artical/show.php?id=1573>浏览器不支持嵌入式框架或配置为不显示嵌入式框架</iframe></td></tr></table>

复制代码

ymd

尽管看得出是高手所作，但我不得不说一句不想说的话，“脱掉裤子放屁！”

masterhe

最初由 ymd 发布
[B]尽管看得出是高手所作，但我不得不说一句不想说的话，“脱掉裤子放屁！” [/B]

确实是“脱掉裤子放屁！” ，并且这是“怕死客”或“呆儿乏”编程者转行玩VC后的第一个习作。

fyje

主题就是：有感于MFC库代码之去简就繁、之故弄玄虚 ，所以才是这样的

rave

最初由 fyje 发布
[B]主题就是：有感于MFC库代码之去简就繁、之故弄玄虚 ，所以才是这样的 [/B]

你有认真读过 MFC  的源代码吗?！
MFC 代码条理清楚，应该还算简洁

沉沉

这贴子到底是扣分还是加分啊？
都为什么？

fyje

最初由 rave 发布
[B]

你有认真读过 MFC  的源代码吗?！
MFC 代码条理清楚，应该还算简洁 [/B]

我声明一点，这篇文章不是我写的，作者的目的是“非议MFC宏和类型定义”，所以夸大化的写了这篇文章，你们可以赞同，也可以反对，仁者见仁，智者见智，我只不过拿出来让大家看看，也没有破坏本论坛的学习研究气氛，没必要把气撒到我身上!
    至于masterHe先生所说的是Delph和pascali转行做的第一个程序，这一点是错误的，这是一个对MFC十分了解的人的作品。
    大家都是作程序的，最好是不要太武断了！认同的观点可以认同，不认同的一笑了之也就行了，没必要大张旗鼓，我也作了十年程序了，在某些方面向你们学习的东西也很多。
  文章出处的网友评论和这里的评论绝对不一样的，那里的评论对MFC的不足和宏的优缺点进行了很认真的讨论。

下面摘几个：

fengye(2003-1-25 12:42:38)  
不知道大家为什么对宏这么反感。对于很多目的而言，宏目前至少还是最合适（唯一？）的解决方案。
我认为MFC的做法都是有历史和现实的道理的：
1. 平台和编译器的可移植性。绝大多数可移植的库，都有大量的宏用来处理移植性问题。比如INT,UINT,DWORD等。另外诸如AFXAPI, WINAPI这类宏，可以被用来处理stdcall, __declspec()等现有或者将来可能会有的扩展。
2. 向后兼容。比如LPINT中的L，曾经在win16时代用来区分FAR指针和NEAR指针，为了保证向后兼容性，一直留到现在。
3. 易读性。比如上面的HOBJ。
4. 语言兼容。大家都知道COM是一个和编程语言无关的二进制标准，为了避免给C和C++分别提供头文件，可以用宏的方式，来改变对函数原型的各种声明，使它在C和C++编译器下都可以编译，并且在C++编译时，充分利用C++的优点（如const member function）。这样就需要选择是否加extern "C"，是否可以加const表示const member function等等。上面定义class, private等关键字也可以用于此类目的。另外一个例子，我还见过用宏把C的语法结构，关键字定义成类似PL/I的样子，唯一目的就是减少对当时项目中大批PL/I程序员的培训成本。
宏的用法当然不只这些，大家有兴趣可以继续归纳。上面文章里的我觉得都可以归为这几类了。MFC确实大量运用了宏，但以次指责MFC我认为是不恰当的。

Cybergate(2003-1-25 13:31:56)  
同意fengye的。
没办法，C++又不是微软的，它总不能自己硬性规定关键字的意义（例如int就是３２位，不管在什么机器上），只好利用宏；另外，VC刚刚出来时，新的ISO标准还没出炉，它也不愿意肆意地为C++扩充功能（像CB那样）。
如果它这样做了，恐怕骂微软的人会更多，骂他又垄断C++。微软吃的官司还少了吗？它这样做是没有办法的。

bluebeach(2003-1-26 1:17:08)  
fengye说的很对.不要被表面的代码晦涩所麻痹.
能解决实实在在的问题才是最有用的.

zqrjx(2003-1-26 18:43:12)  
太多用宏的确不好。但 MFC 是一个例外，它的宏基本都是好的。 int 或者 INT 或者 DWORD 或者 SOCKET 或者随你用，用 int 最标准的，但可读性最差。
宏不增加使用难度（它作用正好相反），只是增加学习难度！
如果因为用宏而做成 BUG ，那就是宏的错，目前 MFC 的宏没有 BUG，所以目前 MFC 的宏没有用错。

cphj(2003-1-27 17:27:12)  

TO all:
我坚决同意在考虑平台和编译器的可移植性的时候，宏是目前较好的解决方案。

TO fengye：
对宏肯定不能赶尽杀绝，但滥用也不好。
1.同意。
2.LPINT中的L确实没必要，现在Win2000都不支持16位代码了。不知道.NET里面有没有改变。
3.不同意。我觉得void *就比HOBJ易读，不过也可能是个人感觉（见下）。
4.const、class、private等都是我瞎掰搞笑的，MFC是直接使用的，你可别当真啊。

TO zqrjx：
我还是觉得int比INT、DWORD、SOCKET的可读性好，因为对int有直接的概念，而看到DWORD还是要在脑海中翻译成int。我早先倒是听一个数学家说过，每个人脑子的思维方式是不一样的，是不是我们的思维方式正好相反？基于同一原因，我觉得宏既增加使用难度又增加学习难度。
是不是可以建立一个投票，看看持两种意见（也就两种思维方式）的各占多少。

ymd

我个人的经验是开发软件期间应尽量少使用宏，但版本升级时为使代码
能正常编译或代码易读，再使用宏，总之#define越多，除编码者外，看
起来就越难懂。

bbu

好高深，向各位学习