※ 引述《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