我为什么讨厌MFC?
喜欢一样事物需要理由么?不需要!那讨厌一件需要理由么?我想,应该需要吧.
"我讨厌MFC!"曾经我对一个同行说过这句话,他说:"你有资格讨厌MFC,因为在wince下,MFC会影响速度".咋一听起来似乎还挺有道理,但再想想,完全是假话.
MFC会影响速度?这句话如果放在两年前,可能是正确的,因为那时候的嵌入式设备CPU速度确实不快.但现在呢?动辄至少就300MHZ的速度,MFC能影响多少效率?何况我做的不是工业级的操控,而是应用级的产品,即使是C#的速度,我也是完全可以接受的----当然,我还是不会用C#去写代码,虽然速度属于我可接受范围,但为了运行C#代码而加入的.NET精简类库而导致的OS的体积膨胀,我是无法接受的----本来OS才9M,加一个.NET精简框架至少让其再臃肿3M!
讨厌总该有理由,我不如回想什么时候让我感到MFC的无奈.
一年前之久,写个计算器,需要有普通型和科学性两种界面.界面不同,但里面的计算过程是相同的.所以,我就想两个不同的对话框,同用同样的一个消息处理函数,也即同一个.cpp文件.但在MFC里,我实在找不到有任何方法让我的想法赋之于实践.无奈,我只好再重建一个CPP文件,然后把原来的处理代码COPY->PASTE.
半年之后,产品打算不使用explorer,而是自己做UI.只是发现去掉Explorer之后,一个非常简单,默认生成的对话框程序,居然会出错!实在无法想象,为什么在WINCE下,MFC需要explorer才能正常工作!无奈,只好用SDK写UI.
两个月之前,想实验一个极度无聊加变态的想法,就是让程序需要调用N次PostQuitMessage()才能退出程序.只是我在生成的程序架构里,我根本没找到那个熟悉的TranslateMessage().无奈,我只好又拿起API.
所以,现在,写代码,已经习惯不去碰MFC,因为怕到时候有什么稀奇古怪的想法,MFC里我无法实现.
还有一点就是,MFC里自动生成的代码,我实在看不懂,却偏偏让它在我程序里呆着----不爽!
说白了,其实我讨厌MFC的理由真的太简单了,仅仅是因为自己的能力不足,无法驾奴MFC.只是,这真的可以成为我讨厌MFC的理由么?
"我讨厌MFC!"曾经我对一个同行说过这句话,他说:"你有资格讨厌MFC,因为在wince下,MFC会影响速度".咋一听起来似乎还挺有道理,但再想想,完全是假话.
MFC会影响速度?这句话如果放在两年前,可能是正确的,因为那时候的嵌入式设备CPU速度确实不快.但现在呢?动辄至少就300MHZ的速度,MFC能影响多少效率?何况我做的不是工业级的操控,而是应用级的产品,即使是C#的速度,我也是完全可以接受的----当然,我还是不会用C#去写代码,虽然速度属于我可接受范围,但为了运行C#代码而加入的.NET精简类库而导致的OS的体积膨胀,我是无法接受的----本来OS才9M,加一个.NET精简框架至少让其再臃肿3M!
讨厌总该有理由,我不如回想什么时候让我感到MFC的无奈.
一年前之久,写个计算器,需要有普通型和科学性两种界面.界面不同,但里面的计算过程是相同的.所以,我就想两个不同的对话框,同用同样的一个消息处理函数,也即同一个.cpp文件.但在MFC里,我实在找不到有任何方法让我的想法赋之于实践.无奈,我只好再重建一个CPP文件,然后把原来的处理代码COPY->PASTE.
半年之后,产品打算不使用explorer,而是自己做UI.只是发现去掉Explorer之后,一个非常简单,默认生成的对话框程序,居然会出错!实在无法想象,为什么在WINCE下,MFC需要explorer才能正常工作!无奈,只好用SDK写UI.
两个月之前,想实验一个极度无聊加变态的想法,就是让程序需要调用N次PostQuitMessage()才能退出程序.只是我在生成的程序架构里,我根本没找到那个熟悉的TranslateMessage().无奈,我只好又拿起API.
所以,现在,写代码,已经习惯不去碰MFC,因为怕到时候有什么稀奇古怪的想法,MFC里我无法实现.
还有一点就是,MFC里自动生成的代码,我实在看不懂,却偏偏让它在我程序里呆着----不爽!
说白了,其实我讨厌MFC的理由真的太简单了,仅仅是因为自己的能力不足,无法驾奴MFC.只是,这真的可以成为我讨厌MFC的理由么?
