作者: jsbjgk (戰鬥吧!!!!!) 看板: C_and_CPP
標題: Re: [問題] .net跟mfc
時間: Mon Apr 3 05:19:18 2006
※ 引述《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:太豐富了,獲益良多,謝謝~~~ :D 04/03 09:05
推 HZYSoft:大推,寫得真精闢!完全寫出所有 mfc programmers 的痛! 04/03 09:08
推 godfat:大推 XD 04/03 12:23
推 drkkimo:說的好呀~ 04/03 13:53
推 pico2k:+1 04/03 14:40
推 ledia:good 04/04 01:05
推 yudsx:推!! 04/04 13:27
推 UNARYvvv:讚啦! 推~ 04/04 22:16
推 horngsh:好!好!好! 07/17 17:57
沒有留言:
張貼留言
您好.本資料庫並非第一手資料.如果你有對文章作者的詢問,意見與需求,請自行找尋文章作者並提供意見,謝謝.