※ 引述《voidmain (WUWUWU)》之铭言： : 那还是想请问各位大大 : MFC现在开发程式时，是用在哪一部份 : 那该部分是否会有被取代的机会呢 : 公司只有提供VC++那麽不就一定要学习MFC 学习 MFC 与其他对等的 framework 最大的不同是... "你必须与 整个系统 奋战... 不能只是躲在 mfc 本身的 class 中度日" (所谓整个系统 包含 win32 api , 一堆系统的函式库 dll档 COM元件... 记忆体管理 多执行绪 加上 微软一堆没写清楚的 MSDN 文件) 这是它让很多人觉得不好用的地方... 到头来 你还是要去尝试 win32 sdk 的传统写法 才能克服一些问题... 在一长串的 mfc 专案程式码中... 对於初学者来说 最令人头痛的大概就是 例如: 到底 A 函式 是来自於 class 或是某个自定义的 h 档还是 win32 api ... (所以我习惯在 全域函式前加上 :: 好让我下次看到时 可以马上区分出来) 另外 我应该在哪里初始化 我的结构 或是我的某个元件... 是 某类别的 建构子 还是 某个以 init... 为名的 Override 函式... 所以当你能够用 mfc 当作你可以上手的武器 而挥洒自如... 你至少克服以下问题 1. 对传统 C 中的 指标 指指标 阵列运用自如 而且知道她们之间的记忆体分配关系 2. 对 C++ 如何实作物件导向的架构有所了解 而且搞懂 这些实作手段跟 1. 的关系 3. 可以从 win32 api 中找出你要的函式 而且 "不痛不痒" 的放在 mfc 的程式码中 (试试看 再 mfc 中写 winsock 程式 或是 directX 的程式 你会有所体悟 话说连 微软的 DirectX demo 用程式 for c/c++ 都是纯粹的 win32 sdk... Orz) 4. 搞清楚那些事情 该在哪个 class 以及哪个 函式中处理... 反过来说 就是搞清楚不要在哪些 class 以及哪个函式中 处理那些事情... 例如说 OnDraw 或是处理介面讯息的地方 绝对不要进行 大量 或是复杂的计算 a.管理资料结构 b.处理介面与视窗内容绘制 c.大量或是复杂的计算 这三种程式 要明确的区分开来...必要的时候要把 c. 的程式码放进多执行绪中.. 如果要玩多执行绪 那又是另外一个问题了... 5. 学了不少 MFC 或是 win32 api 中特有的雕虫小技... 例如:从简单的 如何把视窗定在最上层如同 windows 开始列... 到比较进阶的 读写 registry , 写出自己的 dll 或是控制台元件 , 系统服务... 或是跟该死的 COM , automation 机制 奋战 ... 你看 ... 真是一条漫长的道路啊... 而当你好不容易克服这些该死的历史文件...或从某个好心的论坛中 找出艰深难懂的 程式码可以拿来用... 写出一个具有强大功能的程式... 你也许又会被挑剔... 介面没有风格... 太普通... 然後你的老板(指导教授?) 或是某个脑残的 end user... 手指某个美工一级棒的网页 或是像 office , Dreamweaver , 3D studio MAX 这样的大软体... 说: "我想要这个介面" 或是 "我要这个风格的选单 按钮" .... 之类的... 你的灾难又来了... 由於 mfc 先天的特性使然... 要大幅度的更动介面风格... 超麻烦的... (话说不久前 我还需要从 CHtmlView 衍生个类别 然後把 html 的东西放在 资源中 来生出看起来像是 网页的介面... ) 光是生出某种特定风格的介面... 我相信就是许多 MFC 程式设计人员的痛... 如果有拿到现成的元件 source code 之类的 那就省力很多... 不然 看是要 Custom Controls 还是要用一堆 ActiveX 元件去拼... 或是四处找图来玩 BitmapButton ... 反正免不了 又是一番苦工还有 re-search (不是研究... 而是反覆搜寻...) 呼 打了那麽多... 除了发泄一下怨念外... 最重要的是要告诉 还没学 MFC 正在考虑要不要学的人几件事... 1. 不打算学通 从 C/C++ , win32 sdk , MFC 整套功夫的人... 乾脆不要学 MFC 你有更多省力气的选择... 2. 如果介面是你开发的专案 占很大比重部分的属性的人 那也不要来碰 MFC... Web-Based 的技术才是你最好的选择... 3. 不想去接触 视窗作业系统 一些阴暗 不为常人知的奇行怪癖... (例如: 控制台元件原来只是一个 副档名为 CPL 的 DLL 或是 系统寻找 程式需要的 DLL 档案的路径顺序...) 只想呼叫现成的函式 就想把问题解决的人 你也不适合来碰 MFC... 呵呵 讲了那麽多 MFC 的坏话 那他到底有那些好处... 其实 MFC 本来就是作为 win32 sdk 的强化而诞生的 如果你不需要 win32 sdk 就能轻松解决你的问题 那又何苦来碰 MFC... 反之 如果你需要 搬出 win32 sdk 来打仗时... MFC 会是额外负担最少... 最精确的 win32 sdk "发射载具" 例如 : VB 也可以呼叫 win32 api 啊 可是当你 需要明确的控制指标或是 指指标为型式的资料时... 甚至要 1byte 1byte 的读写资料时... 你一定恨死 VB 了... 而与 delphi / BCB 相比... 微软自家人的优势 让你确保了只要有 微软本身提共的 .h 与 .lib 你就可以精确的呼叫你想要的... 而不用再找合适的 内有正确的 #ifdef #define 条件的 .h 或是特定的 .lib (Borland 花了不少时间在产生这些东西上面...) 如果你很清楚的知道 并且善用 release with static linking 的产生方式... 要撰写特殊功能的系统工具或小元件 且又必须适用於 win98 / win2k / winxp 包含一堆 有更新/没更新 有灌特殊软体/没灌特殊软体的环境... 你绝对可以产生体积最小 额外指令最少... 而且只依赖 windows 原生的 gdi / kernel / user 三大模组的执行档... 同时享受 MFC 带来的一些便利性...(相对於只有 win32 sdk 而言) 当然其他开发工具也有做得到的 但是 MFC 是最小而且最少的...除非你要用 win32 sdk 来写 ※ 编辑: jsbjgk 来自: 218.171.214.30 (04/03 05:21)