Re: [問題] .net跟mfc

看板C_and_CPP (C/C++)作者HZYSoft (PCMan 2004)時間18年前 (2006/04/03 09:13)推噓2(2推 0噓 0→)

留言2則, 2人參與討論串3/3 (看更多)

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