作者horngsh (展翔研究室)
看板Programming
標題Re: [討論] .net有可能取代mfc嗎?
時間Fri Jun 18 09:48:53 2010
※ 引述《garymouse (火星來的老鼠)》之銘言：
: 同意,QT,MFC這類的東西確實沒有比VCL甚至C#來得好用,但是
: 至少在視窗的開發上面從Win 32 API到MFC都是觀察一個視窗
: 怎麼誕生、工作、閒置到死亡(destory)的最好工作語言,知道
: 了這些原理,至少在高階程式語言也較容易上手,也不害怕修
: 改,甚至改錯方向,本來使用高階語言已經肥了,為了功能硬是
: 修改,不是肥上加肥嗎?就某些產業來說,就算MCU的容量很大,
: 明明可以使用OOP來做的事,有些功能公司還是要我們使用組
: 合語言來開發,這對於一些新手,只知道call function,確不
: 解其道理而言,更是苦不堪言。
Win 32 API沒那麼高深吧, 一些基礎面且底層的東西不是沒有人知道, 想知道
底層可以去看PetZolds的Programming Windows 5th, Window Handle,
RegisterWindow, ShowWindow, DispatchMessage, Window Procedure,這一些東西
因為很古老, 所以有很多新手都不知道, 每個人的特性都不一樣, 有的人要追根究底
才會滿足(像侯老大), 有的人只要會依樣畫葫蘆就可以了, 不能一概而論, 當你發現
無解的BUG時, 你才有必要去懷疑是不是底層的API或LIB有BUG, 這時候也才是動用
組合語言的時候, 以前DOS下古老的Clipper的某個SaveScreen函式有BUG, 也是在最後
關頭才去懷疑是Clipper的函式有BUG, 動用反組譯發現的, "除非必要", 才去懷疑
系統API或LIB有BUG, 用Framework如VCL或.NET或JAVA framework, 才是目前"快速"
開發的王道啊, 就像沒有人像侯老大那麼有恆心去TRACE C++ STL SOURCE Code一樣,
除非你是要自己開發自己的Framework, 那就另當別論了.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 112.104.191.119
1F：推 hilorrk:我只是普通人... 140.118.33.155 06/18 10:48
2F：推 cgcheng:STL已經不變很久，可以改trace boost 218.161.56.57 06/20 18:12
3F：→ cgcheng:應該說變動性不頻繁，有點講錯 218.161.56.57 06/20 18:13