Re: [問題] .net跟mfc

看板C_and_CPP作者jsbjgk (戰鬥吧!!!!!)時間18年前 (2006/04/03 02:19)推噓11(11推 0噓 0→)

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

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

推

Xphenomenon

04/03 09:05, , 1^F

04/03 09:05, 1^F

推

HZYSoft

04/03 09:08, , 2^F

04/03 09:08, 2^F

推

godfat

04/03 12:23, , 3^F

04/03 12:23, 3^F