※ 引述《jsbjgk (战斗吧!!!!!)》之铭言： <deleted /> : 学习 MFC 与其他对等的 framework 最大的不同是... : "你必须与 整个系统 奋战... 不能只是躲在 mfc 本身的 class 中度日" : (所谓整个系统 包含 win32 api , 一堆系统的函式库 dll档 COM元件... : 记忆体管理 多执行绪 加上 微软一堆没写清楚的 MSDN 文件) : 这是它让很多人觉得不好用的地方... 岂只是不好用而已... : 到头来 你还是要去尝试 win32 sdk 的传统写法 才能克服一些问题... : 在一长串的 mfc 专案程式码中... : 对於初学者来说 最令人头痛的大概就是 例如: : 到底 A 函式 是来自於 class 或是某个自定义的 h 档还是 win32 api ... : (所以我习惯在 全域函式前加上 :: 好让我下次看到时 可以马上区分出来) 看参数型态就知道了，MFC member function 一般比 Win32 API 少掉第一个参数 因为变成 this 了 = =||| (可见其封装之低劣，根本就是 C++ 版的 Win32 API) : 另外 我应该在哪里初始化 我的结构 或是我的某个元件... : 是 某类别的 建构子 还是 某个以 init... 为名的 Override 函式... 补充，不同类别能放的地方全部都不一样 CDialog::OnInitDialog, CWnd::PreCreateWindow, CWnd::OnCreate, CView::OnInitialUpdate 放错地方程式多半会当，而且很多东西都不可以在 contructor 里面做 完全彻底的违反了 C++ 的设计和精神 : 所以当你能够用 mfc 当作你可以上手的武器 而挥洒自如... : 你至少克服以下问题 : 1. 对传统 C 中的 指标 指指标 阵列运用自如 而且知道她们之间的记忆体分配关系 还要熟悉 Macro 的使用 = =，还有要习惯不要被一些完全不像 C/C++ 的东西吓到 : 2. 对 C++ 如何实作物件导向的架构有所了解 而且搞懂 这些实作手段跟 1. 的关系 不见得，不用很懂物件和 C++ 一样可用 MFC，MFC 没有多重继承，好像也没有虚拟继承 没有 namespace... 等等，反正比正常的 C++ 程式少了一卡车东西，又多了一堆 macro : 3. 可以从 win32 api 中找出你要的函式 而且 "不痛不痒" 的放在 mfc 的程式码中 : (试试看 再 mfc 中写 winsock 程式 或是 directX 的程式 你会有所体悟 说到 winsock，在此提醒各位朋友不要用 MFC 的 CSocket 类别 那个效能很差，而且会卡死 GUI，并且在 multi-threading 会当掉 除了 MFC 的范例以外，我从来没有看过谁用那个写 socket 程式 : 话说连 微软的 DirectX demo 用程式 for c/c++ 都是纯粹的 win32 sdk... Orz) : 4. 搞清楚那些事情 该在哪个 class 以及哪个 函式中处理... : 反过来说 就是搞清楚不要在哪些 class 以及哪个函式中 处理那些事情... : 例如说 OnDraw 或是处理介面讯息的地方 绝对不要进行 大量 或是复杂的计算 : a.管理资料结构 b.处理介面与视窗内容绘制 c.大量或是复杂的计算 : 这三种程式 要明确的区分开来...必要的时候要把 c. 的程式码放进多执行绪中.. : 如果要玩多执行绪 那又是另外一个问题了... MFC 遇上多执行绪会颇麻烦，不小心就会烂掉，而且必须照 MFC 的规矩来 必须乖乖用 AfxBeginThread 那类的东西，这里不能直接用 Win32 API，否则会有问题 轻则 memory leak，重则 mfc 的东西不能正常使用 : 5. 学了不少 MFC 或是 win32 api 中特有的雕虫小技... : 例如:从简单的 如何把视窗定在最上层如同 windows 开始列... : 到比较进阶的 读写 registry , 写出自己的 dll 或是控制台元件 , 系统服务... 其实上面网友举例的全是 Win32 API.... MFC 一点忙都没有帮到.... = : 或是跟该死的 COM , automation 机制 奋战 ... : 你看 ... 真是一条漫长的道路啊... <deleted /> : 然後你的老板(指导教授?) 或是某个脑残的 end user... : 手指某个美工一级棒的网页 或是像 office , Dreamweaver , 3D studio MAX : 这样的大软体... : 说: "我想要这个介面" 或是 "我要这个风格的选单 按钮" .... 之类的... : 你的灾难又来了... : 由於 mfc 先天的特性使然... 要大幅度的更动介面风格... 超麻烦的... 真的是超麻烦，并没有比直接写 Win32 API 方便多少，我後来乾脆就直接用 API : 光是生出某种特定风格的介面... 我相信就是许多 MFC 程式设计人员的痛... : 如果有拿到现成的元件 source code 之类的 那就省力很多... 完全同意！！ <deleted /> : 3. 不想去接触 视窗作业系统 一些阴暗 不为常人知的奇行怪癖... : (例如: 控制台元件原来只是一个 副档名为 CPL 的 DLL 其实不完全一样，但只有程式的进入点不太一样 : 呵呵 讲了那麽多 MFC 的坏话 那他到底有那些好处... : 其实 MFC 本来就是作为 win32 sdk 的强化而诞生的 : 如果你不需要 win32 sdk 就能轻松解决你的问题 那又何苦来碰 MFC... : 反之 如果你需要 搬出 win32 sdk 来打仗时... : MFC 会是额外负担最少... 最精确的 win32 sdk "发射载具" <deleted /> jsbjgk 这篇真的是好文，写得超精辟！ 完全道尽 mfc programmer 的悲哀 MFC 基本上是 windows 3.1 时代的设计了，至今架构没有多少改变 VC++ 精灵生出的 dialog-based MFC 程式里面竟然还有相容 Win 3.1/NT 3.5 的程式码 如果还是有人要问，都 2006 年了，为何还一定要学 mfc 这种十几年前的产品 简单归纳之後，我觉得大概只剩下五个理由： 1. 必须维护古时候的程式 2. 必须维护古时候的程式 3. 必须维护古时候的程式 4. 必须维护古时候的程式 5. 必须维护古时候的程式 MFC 根本就是加上物件的 Win API，有封装跟没装真的是差不多的! 现在除非老板要求，工作需要，不然千万不要再浪费时间学了啦! -- 个人网页： http://pcman.sayya.org/ 上面有自画像及各种联络资讯 PCMan 全系列 BBS 连线软体 http://pcman.ptt.cc/ http://pcmanx.csie.net/ 新酷音输入法 for Windows http://chewing.csie.net/ IE Tab Firefox plugin/extension http://ietab.mozdev.org/ PCMan 油画作品集：http://www.wretch.cc/album/album.php?id=pcman&book=1 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 218.161.125.165