作者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