OWL vs. MFC ?
尚未認證通過!?
呵...每隔一段時間, 就會有人把OWL 跟 MFC拿出來辯論一頓,
每次也會為程式設計版增加一堆文章
我個人兩方面都曾用過一段時間, 而且是先學OWL的
OWL確實比較容易使用, 也較物件化
但若光以 OO 角度來看, 其實差異點在 VC++ 和 BCB 的Compiler就發生了
主要在Compiler做法上的不同, 使得VC++在多重繼承上會有些限制
其他也有一小部份並沒有達到ANSI C++的目的
並且影響到MFC架構有些部份要以MACRO來完成，而使得整個架構變得有點怪怪的
我剛學完OWL, 再學MFC時, 也不得不苦笑 (後來在看 VB 時已經臉都黑掉了)
但MFC較廣為使用是事實, 軟體的世界本就是如此,
程式設計的好壞原本就跟市場占有率是兩回事, 這也沒什麼好不平的
既然走這行, 就要有這種體認
講到Inprise 後來改打VCL, 我覺得其實已經把目標改到RAD市場,
而應該跟VB, DELPHI等做比較才對, 而非VC++了
至於我自已也早就改用VC++ 和 MFC 了, 實在是因為他的勢力太龐大
而且很多3rd party 的東西只支援到VC++
其實OWL跟MFC都只是一種工具
MFC用習慣了, 也一樣用得很順, 甚至也開始覺得VC++好用
我想這就是為什麼大家都會為自已慣用的東西辯護的原因吧?
--
[m [1;31m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 203.67.177.231] [m
dcam
> 呵...每隔一段時間, 就會有人把OWL 跟 MFC拿出來辯論一頓,
> 每次也會為程式設計版增加一堆文章
> 我個人兩方面都曾用過一段時間, 而且是先學OWL的
> OWL確實比較容易使用, 也較物件化
> 但若光以 OO 角度來看, 其實差異點在 VC++ 和 BCB 的Compiler就發生了
> 主要在Compiler做法上的不同, 使得VC++在多重繼承上會有些限制
> 其他也有一小部份並沒有達到ANSI C++的目的
> 並且影響到MFC架構有些部份要以MACRO來完成，而使得整個架構變得有點怪怪的
Borland 也改過 (BC++ 3.1) C++ compiler 語法以支援 OWL 的特殊用法
後來到 4.0 又改回用 Macro 方式
> 我剛學完OWL, 再學MFC時, 也不得不苦笑 (後來在看 VB 時已經臉都黑掉了)
> 但MFC較廣為使用是事實, 軟體的世界本就是如此,
> 程式設計的好壞原本就跟市場占有率是兩回事, 這也沒什麼好不平的
> 既然走這行, 就要有這種體認
> 講到Inprise 後來改打VCL, 我覺得其實已經把目標改到RAD市場,
> 而應該跟VB, DELPHI等做比較才對, 而非VC++了
> 至於我自已也早就改用VC++ 和 MFC 了, 實在是因為他的勢力太龐大
現在學生用 BCB 好像是居多了
> 而且很多3rd party 的東西只支援到VC++
> 其實OWL跟MFC都只是一種工具
> MFC用習慣了, 也一樣用得很順, 甚至也開始覺得VC++好用
> 我想這就是為什麼大家都會為自已慣用的東西辯護的原因吧?
VC Built-in 的 tools (Class Wizard/Debugger/Profile) 的確相當好用
可惜 Borland 的市場被吃掉，改走 VCL，放棄 OWL
Jim McCarthy 的確厲害，帶領 Compiler 團隊在短短幾年間
把 Microsoft C Compiler 轉型成 Visual C++
而且把 Borland 的優點都抄走，更增加對 OLE2/WinSock/... 等支援
那個年代 OLE2 可是很紅的，可惜 Borland 的支援雖好，但又不融合在
OWL 中，結果輸了這場戰役了。
同時出局的還有 Symantec C++/Watcom C++ 唉
到底有多少人用了 OLE2 的 Compound Document呢?
倒是來寫 VB/VC 的 OLE Custom Control 比較多吧.
我買過的兩個 C++ Compiler: Borland C++ 4.0~ 4.5，VisualAge C++ 3.0
現在只有 IBM 還在撐了，但是只怕剩下 Workstation 版了。
Bye bye OWL/Borland
--
[1;33m※ Origin: [36m奇摩 大摩域 [37m<telnet://bbs.kimo.com.tw> [m
[1;35m◆ From: [1;32m211.20.100.166 [m
司馬仲達
其實本來也不想加入戰局
實在是有人瞎掰的太厲害^^
連Application Framework等級的東西
也可以說成和RAD開發速度不相上下
昏倒 -___-
而且原本好像
還搞不懂BCB(VCL)和BC++(OWL)的不同
不喜歡直說哪個產品比較好
(總是互有擅長之處嘛,像VC編譯出的程式真的跑比較快)
但是總得更正錯誤的說法
以免誤導板上的初學者
> 我個人兩方面都曾用過一段時間, 而且是先學OWL的
> OWL確實比較容易使用, 也較物件化
> 但若光以 OO 角度來看, 其實差異點在 VC++ 和 BCB 的Compiler就發生了
> 主要在Compiler做法上的不同, 使得VC++在多重繼承上會有些限制
> 其他也有一小部份並沒有達到ANSI C++的目的
> 並且影響到MFC架構有些部份要以MACRO來完成，而使得整個架構變得有點怪怪的
> 我剛學完OWL, 再學MFC時, 也不得不苦笑 (後來在看 VB 時已經臉都黑掉了)
> 但MFC較廣為使用是事實, 軟體的世界本就是如此,
也不只是軟體這樣^^
叫好不叫座 的現象其實滿普遍的
> 程式設計的好壞原本就跟市場占有率是兩回事, 這也沒什麼好不平的
> 既然走這行, 就要有這種體認
> 講到Inprise 後來改打VCL, 我覺得其實已經把目標改到RAD市場,
> 而應該跟VB, DELPHI等做比較才對, 而非VC++了
> 至於我自已也早就改用VC++ 和 MFC 了, 實在是因為他的勢力太龐大
我喜歡RAD是因為
我興趣是在資訊方面的應用
能達到我要的設計目標才是最重要的
所以我不會浪費時間在coding方面
那只是完成目標的一種手段罷了
> 而且很多3rd party 的東西只支援到VC++
> 其實OWL跟MFC都只是一種工具
> MFC用習慣了, 也一樣用得很順, 甚至也開始覺得VC++好用
> 我想這就是為什麼大家都會為自已慣用的東西辯護的原因吧?
這倒是^^
--
**********************************************
* Simayi司馬仲達 sim...@kimo.com.tw � *
* ICQ : 49827636 歡迎討論程式設計的問題 *
* C/C++ OWL ASM QB BCB 都可以討論喔!! *
* http://NetCity.hinet.net/vega6385/tech.htm *
**********************************************
--
[1;32m※ Origin: [33m交大資工鳳凰城資訊站 [37m<bbs.csie.nctu.edu.tw> [m
[1;31m◆ From: [36mh245.s127.ts32.hinet.net [m
尚未認證通過
: 呵...每隔一段時間, 就會有人把OWL 跟 MFC拿出來辯論一頓,
: 每次也會為程式設計版增加一堆文章
: 我個人兩方面都曾用過一段時間, 而且是先學OWL的
: OWL確實比較容易使用, 也較物件化
: 但若光以 OO 角度來看, 其實差異點在 VC++ 和 BCB 的Compiler就發生了
視覺化的環境的確需要IDE來配合才行:)
VCL擴充了C++的關鍵字,來提供視覺化的功能與元件威力(主要是事件)
但這都需要IDE來配合運作....
: 主要在Compiler做法上的不同, 使得VC++在多重繼承上會有些限制
: 其他也有一小部份並沒有達到ANSI C++的目的
: 並且影響到MFC架構有些部份要以MACRO來完成，而使得整個架構變得有點怪怪的
當你替元件增加message handler時
C++ Builder 5.0也是利用MACRO來Implement的
這樣做的原因是因為C++是一種公開標準
為了配合標準與儘量維持相容性
MACRO是目前唯一"合法"與有效率的做法...
我若沒記錯的話
Borland C++ and Delphi都有特殊的機制來處理Message Handler的問題
尤其是Delphi
因為Inprise主導Pascal的標準
所以可以利用特殊機制來更有效率與精簡的解決這些問題
甚至包括COM的Interface也可以更有效率..
: 程式設計的好壞原本就跟市場占有率是兩回事, 這也沒什麼好不平的
: 既然走這行, 就要有這種體認
: 講到Inprise 後來改打VCL, 我覺得其實已經把目標改到RAD市場,
: 而應該跟VB, DELPHI等做比較才對, 而非VC++了
Inprise的觀點是
隨著OWL/MFC越來越龐雜與巨大
為了效率與降低程式開發複雜度
Application Framework也面臨了革命的必要性
正如當初MFC/OWL的出現是為了解決API的複雜度
而VCL的出現也是為了解決OWL的使用複雜度
: 至於我自已也早就改用VC++ 和 MFC 了, 實在是因為他的勢力太龐大
: 而且很多3rd party 的東西只支援到VC++
我的看法剛好和您相反
VC使用的人太多了....所以我不去碰很多人都會的東西...
而且這麼辛苦的學MFC.....等到微軟哪天大改版時...那真會讓人哭笑不得...
我是不太清楚新架構.NET和MFC的關係...
但我相信微軟終究有一天會好好整頓"MFC"...
正如他整頓VB一樣....
所以我現在的工作是從事和Java有關的
學一次Java API/Package,任何平台與系統都可以用
: 其實OWL跟MFC都只是一種工具
: MFC用習慣了, 也一樣用得很順, 甚至也開始覺得VC++好用
: 我想這就是為什麼大家都會為自已慣用的東西辯護的原因吧?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
政治板的許多行為
正好表現出人類對於正義，道德，真理，自由，幸福的渴望
以及人類仇恨，幼稚，非理性，無知，狂妄自大的劣根性
人類真是矛盾的綜合體啊～
而歷史的悲劇也往往是這樣誕生的...........
[m [1;34m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 211.72.177.62] [m
何陋居主
> 呵...每隔一段時間, 就會有人把OWL 跟 MFC拿出來辯論一頓,
> 每次也會為程式設計版增加一堆文章
再過一陣子, 連 Borland Kylix 引進的 CLX 恐怕也要加入戰局... 呵...
經過幾年磨練, Borland 工程師應該有辦法做出更好的架構吧。
加上 CLX 是架在 Qt 之上 (不知道會不會也支援 gtk+ ? ) ,
當年與 Novell 合作的 AppWare (???) 跨平台之夢, 希望能成真。
> 講到Inprise 後來改打VCL, 我覺得其實已經把目標改到RAD市場,
> 而應該跟VB, DELPHI等做比較才對, 而非VC++了
OWL 在從 1.0 到 2.0 時, 也改了不少東西。
至於 VCL, 如果沒記錯, 當初因為在 Delphi 上面一炮而紅,
所以當 Borland 想將 BC++ 弄成 RAD 時,
自然優先選擇已歷經嚴酷市場考驗的 VCL 做為 BCB 的元件架構。
反觀 MS, VC++ 一直沒有好的元件架構支撐；
ATL 只能算小兒科, COM/ActiveX 又不能算是專為 VC++ 而打造...
兩者都沒有構築出相當於 MFC 規模的元件體系。
Borland 的 VCL 就有構築出相當於 MFC 及 OWL 規模的元件體系,
但易用性則遠遠勝出。
> 其實OWL跟MFC都只是一種工具
> MFC用習慣了, 也一樣用得很順, 甚至也開始覺得VC++好用
> 我想這就是為什麼大家都會為自已慣用的東西辯護的原因吧?
我也用習慣 C++, 對 Java 較不熟練。
但, C++ 做得不好而 Java 做得好的, 我也不諱言；
縱然我用熟悉的 C++ 硬幹照樣能很快地做出同等功能的應用程式...
翻譯 Design Patterns 過程中, 更是益發感到 Java 的美...
尤其是藉此之便再度仔細研究過 Observer (293)、Decorator (175)、
Chain of Responsibility (223) 這些 patterns 之後,
在讚嘆 Java 之餘,
再回頭看看 MFC, 實在覺得它簡直可當做反面教材... :q
同樣都是 application framework, 同樣都是工具,
設計優劣, 真的有差!
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
≡ 何陋居 ≡ 二十世紀： 輕、薄、短、小、忙、速、動、流；
二十一世紀：創、遊、美、人、樂、夢、悠、未。
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
* Origin: ★ 交通大學資訊科學系 BBS ★ <bbs.cis.nctu.edu.tw: 140.113.23.3>
躍上海面的心情
不像學生的學生
> 哇！william大大正在翻譯Design Patterns?這可真是個大好消息！！
預計何時出版呀?
哪家出版社呢?
真是個振奮人心的好消息.
cview2000
> 哇！william大大正在翻譯Design Patterns?這可真是個大好消息！！
對呀 ... 原著 OMT 的圖會不會加 UML 的版本呢 ?
尚未認證通過!?
: 《 在 bios@TKU-BBS (尚未認證通過!?) 的大作中提到: 》
: : 但若光以 OO 角度來看, 其實差異點在 VC++ 和 BCB 的Compiler就發生了
: 視覺化的環境的確需要IDE來配合才行:)
: VCL擴充了C++的關鍵字,來提供視覺化的功能與元件威力(主要是事件)
: 但這都需要IDE來配合運作....
: 當你替元件增加message handler時
: C++ Builder 5.0也是利用MACRO來Implement的
我原來的意思是指 純以 C++ 的角度來看
暫時不看 OWL 及 MFC 時
BC++ 興 VC++ 的 Compiler 對 C++ 語言的做法就稍有不同
VC++ 先天上對 C++ 語言的支援就有點不良
(我記得主要是多重繼承方面的問題)
而導致 MFC 架構上後天不良
倒是跟您所說的
為了視覺化或 IDE 本身提供的機制是另一回事
(我是光指 Compiler 而已)
可能是我原文中寫了 MACRO 誤導了你的了解
sorry~
: : 至於我自已也早就改用VC++ 和 MFC 了, 實在是因為他的勢力太龐大
: : 而且很多3rd party 的東西只支援到VC++
: 我的看法剛好和您相反
: VC使用的人太多了....所以我不去碰很多人都會的東西...
: 而且技術性也不高...難學又低階(複雜度倒很高)
: ...而且苦幹實幹MFC多年的老鳥也很多
: 去跟這些人在MFC上爭高下
: 輸了贏了都沒有什麼意義
哈哈...好奇怪的想法
我也不喜歡碰很多人會的東西
但是我覺得 MFC 本身只是工具罷了, 技術性當然不高
你該擔心的是用 MFC 寫出來的程式技術性高不高吧??
至於 Ap Framework, 則當然要選比較多人會的
這樣才比較容易跟人家合作工作嘛
不過這是個人選擇啦...
: 而且這麼辛苦的學MFC.....等到微軟哪天大改版時...那真會讓人哭笑不得...
: 我是不太清楚新架構.NET和MFC的關係...
: 但我相信微軟終究有一天會好好整頓"MFC"...
: 正如他整頓VB一樣大改版....
: 或者推出新的Application Framework (視覺化).....
: 所以我現在的工作是從事和Java有關的
: 學一次Java API/Package,任何平台與系統都可以用
: 每一次投資都不受系統所限制...這是提外話.....
: 但Java目前還是不適合用在Client端的GUI...太慢了...
呵.. 這個看法我倒是跟你完全一樣
我原本主要興趣就是在UNIX上
但是之前一直想兼顧到 Windows 的程式設計
直到 .net 出來
我覺得到 MS 新版的速度與幅度太快太大了
(但是實際上都不是解決他本身的問題 而是創造新的架構)
看看 DDE, OLE, OLE2, ActiveX, Com DCOM, 現在又有 .net
OS 每次改版也都會多出一些新玩意, 新概念
學他的東西投資報酬率太差了一點
所以我已經不打算陪 MS 玩下去
不在 Windows 平台上再學新的東西了
除非真的要用到再說
現在也是用 Java 來補這塊
當然不一定是要用來做 Client 的 GUI
真的要做 GUI, 再來用 MFC 就好
--
[m [1;33m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 210.241.155.16] [m
林永恆
: 《 在 bios@TKU-BBS (尚未認證通過!?) 的大作中提到: 》
: : 至於我自已也早就改用VC++ 和 MFC 了, 實在是因為他的勢力太龐大
: : 而且很多3rd party 的東西只支援到VC++
: 我的看法剛好和您相反
: VC使用的人太多了....所以我不去碰很多人都會的東西...
老實說，會Java跟BCB的人也很多
搞不好比會VC的人還多
所以你也不碰bcb跟Java????
: 而且這麼辛苦的學MFC.....等到微軟哪天大改版時...那真會讓人哭笑不得...
我的看法也完全跟你相反
做軟體這一行本來就要隨時追著業界的標準
雖然追的很辛苦
不過，做軟體的本來就要有這種覺悟
不然就不要來做軟體
，況且，微軟大改版又不是每天發生
頂多三，四年發生一次
痛苦也就痛苦那一次
以後又可以撐個三，四年
重點是，這樣的改版是好還是壞
微軟總不會來個大改版，還弄得架構越來越差
當大改版發生，一定是mfc架構到達某一個瓶頸
不得不大改版.....
因此，我樂見大改版的發生
並認它會為我們帶來好處
況且，就算大改版，MFC還是以C++為根本
它總不會連C++的語法，和概念都一起改掉了吧
所以大改版後，你並不會退回到零
還可以享受大改版所帶來的好處
有何好哭笑不得......
不過話說回來..........
MFC自VC4.0以後都沒什麼大改版
好像不只三，四年囉....
: 我是不太清楚新架構.NET和MFC的關係...
: 但我相信微軟終究有一天會好好整頓"MFC"...
: 正如他整頓VB一樣.....
那你有沒有發現VB整頓後很像VC
老實說，vb早就該整頓了
要不是bill gates是以寫Basic起家的
對著Basic還有濃厚的感情
以VB那種架構，早就該被開刀了.......
: 所以我現在的工作是從事和Java有關的
: 學一次Java API/Package,任何平台與系統都可以用
: : 其實OWL跟MFC都只是一種工具
: : MFC用習慣了, 也一樣用得很順, 甚至也開始覺得VC++好用
: : 我想這就是為什麼大家都會為自已慣用的東西辯護的原因吧?
沒錯，但是還有其他因素!!!!!!
--
聽王菲的音樂，然後陷入一種美麗的冥想
聽楊乃文的歌，激發內心最深處潛藏的熱情
聽陳珊妮的歌，激動得想隨著音樂起舞
聽希麗娜依的歌，然後進入一種莫名的悲傷
聽許美靜的歌，很想將對人生的那種深刻體驗化成行動
[m [1;33m※來源 : [1;36m 台北科技大學紅樓資訊站 [1;35mredbbs.cc.ntut.edu.tw
[1;32m※FROM : [1;37m211.20.122.186 [m
尚未認證通過
: 我原來的意思是指 純以 C++ 的角度來看
: 暫時不看 OWL 及 MFC 時
: BC++ 興 VC++ 的 Compiler 對 C++ 語言的做法就稍有不同
根據侯俊傑的說法
VC compiler對於C++實做的最佳化,是要比C++ Builder好
(尤其是在多重繼承和虛擬函數方面)
不過當時他是指VC5 vs BCB3....
: VC++ 先天上對 C++ 語言的支援就有點不良
的確...VC對C++語言的支持與反應往往是要比C++ Builder慢...
: (我記得主要是多重繼承方面的問題)
: 而導致 MFC 架構上後天不良
這我倒是沒有聽過...
不過mfc應該是多重繼承的架構
但是VCL是單一繼承....
至於MFC難用的原因到底是不是因為多重繼承方面的問題
其實是可以好好討論的....(我是沒這個功力:Q)
不過我記得OWL也是多重繼承的吧??(不知道有沒有記錯)
但是OWL卻很乾淨漂亮..
: 倒是跟您所說的
: 為了視覺化或 IDE 本身提供的機制是另一回事
: (我是光指 Compiler 而已)
: 可能是我原文中寫了 MACRO 誤導了你的了解
: sorry~
小事情...小事情...:)
不過我個人想進一步闡述的觀點是
你提到的compiler,應該是指如何實做的細節
這方面的差異應該只是產生的程式碼大小與效率的問題
和Class/Application Framework沒有關係才是吧?
我個人的認知是
OWL/MFC應該都算是標準C++的Application Framework
Macro的運用也算標準的C++語法應用
兩者的相比,應該只是架構好壞的問題
是不是比較符合物件導向精神的問題
和Compiler如何實做封裝繼承虛擬函數表等資料結構沒有關係拉..
至於VCL這種RAD Application Framework
IDE環境就扮演非常重要的腳色
因為在我們拉拉元件產生畫面的時候
IDE就必須根據C++程式碼,以及擴充的關鍵字
動態產生與初始化這些元件
甚至加以檢查起始元件的資料是否合法
而我們對畫面的變動,IDE也會同步反應在程式碼上
這是VC的IDE環境所欠缺的...
因此我可以這樣說,VCL必須依靠IDE的支援才能發揮威力
否則仍然沒有視覺化的可能......
VB的IDE在某個方面來說也是符合這個條件
但他的致命傷在於IDE介入太深,形成過多的黑箱作業
程式碼無法反應與描述這中間的很多細節
而且VB語法缺乏很多重要的物件導向特色
更沒有對於RAD的語法支援與控制
反觀Delphi就完全避免掉這些問題....
OOPascal是要比VB強大很多....
所以我的看法簡單的來說
是把討論的細節區分成三塊
一是Compiler實做的細節(這塊比較獨立)
二是ApplicationFramework/Class實做的架構與精神
三是IDE環境所扮演的腳色與和第二項的結合
平安
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
政治板的許多行為
正好表現出人類對於正義，道德，真理，自由，幸福的渴望
以及人類仇恨，幼稚，非理性，無知，狂妄自大的劣根性
人類真是矛盾的綜合體啊～
而歷史的悲劇也往往是這樣誕生的...........
[m [1;33m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 211.72.177.62] [m
尚未認證通過
: : : 至於我自已也早就改用VC++ 和 MFC 了, 實在是因為他的勢力太龐大
: : : 而且很多3rd party 的東西只支援到VC++
: : 我的看法剛好和您相反
: : VC使用的人太多了....所以我不去碰很多人都會的東西...
: 這是什麼邏輯呢!!!!!
: 老實說，會Java跟BCB的人也很多
: 搞不好比會VC的人還多
: 所以你也不碰bcb跟Java????
Sorry,我先更正一下我原先的錯誤
我是說MFC(不是指VC這個工具)會的人太多了,而且難學難用架構不好
所以沒有迫切的必要走回頭路去跟這些人比熟悉MFC
同樣的事情
BCB/VCL可以更快更漂亮的解決
還不如去把VCL/BCB學好學透徹
再說Linux大勢已成
今天學BCB/VCL
透過Kylix等於同時學會在Linux上寫RAD程式
投資報酬率遠高於和一群人去在MFC上打轉...
再來,在台灣會Java的人遠少於C++
所以算是炙手可熱
更不要說會JavaBean, LDAP/JNDI, JDBC/Servlet/JSP的Java人才更是難找.
若是一個技術很先進或強大
即使人多也該去好好學學
但若此項技術已經到瓶頸,又不夠先進
還是另謀出路比較聰明
: : 而且這麼辛苦的學MFC.....等到微軟哪天大改版時...那真會讓人哭笑不得...
: 我的看法也完全跟你相反
: 做軟體這一行本來就要隨時追著業界的標準
: 雖然追的很辛苦
: 不過，做軟體的本來就要有這種覺悟
: 不然就不要來做軟體
先決條件是你要看得出來哪種技術有潛力,夠先進
學了以後大家爭相高薪挖你...
這種技術就要好好學,越早學越好
資訊業一大堆新技術新名詞新規格
消失在泡沫中的技術數都數不盡
我們沒有那麼多的美國時間胡亂追
: ，況且，微軟大改版又不是每天發生
: 頂多三，四年發生一次
: 痛苦也就痛苦那一次
: 以後又可以撐個三，四年
: 重點是，這樣的改版是好還是壞
: 微軟總不會來個大改版，還弄得架構越來越差
: 當大改版發生，一定是mfc架構到達某一個瓶頸
: 不得不大改版.....
說的很好
我就是看到MFC已經到瓶頸
所以不想浪費自己的時間去深入學習MFC :)
等他改版之後再學豈不聰明??
更何況比MFC好的技術與架構又不是沒有
再來我告訴您
若真要改版
很有可能是推出全新的Application Framework
絕不是MFC的改版...(盤根錯節與包袱太多,太困難了)
這也是Inprise用全新的VCL來取代OWL的原因
到時候所有的MFC經驗可以說幾乎都派不上用場..
多年投資化為烏有
: 因此，我樂見大改版的發生
: 並認它會為我們帶來好處
對啊...把那些MFC老鳥的經驗重新reset
: MFC自VC4.0以後都沒什麼大改版
: 好像不只三，四年囉....
已經到瓶頸了...
何陋居主
> > 哇！william大大正在翻譯Design Patterns?這可真是個大好消息！！
> 對呀 ... 原著 OMT 的圖會不會加 UML 的版本呢 ?
已全部改成 UML, 不過會在附錄 B 加些註解簡介兩者的不同.
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
≡ 何陋居 ≡ 二十世紀： 輕、薄、短、小、忙、速、動、流；
二十一世紀：創、遊、美、人、樂、夢、悠、未。
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
何陋居主
> > 哇！william大大正在翻譯Design Patterns?這可真是個大好消息！！
> 預計何時出版呀?
> 哪家出版社呢?
> 真是個振奮人心的好消息.
出版社是 Pearson 培生, 也就是 Addison-Wesley 與 Prentice 合併後的那家公司.
預計 4/6 全部完稿, 如果順利, 希望兩個禮拜左右問市吧.
如果一切順利... :q
何陋居主
> > 哇！william大大正在翻譯Design Patterns?這可真是個大好消息！！
> 預計何時出版呀?
> 哪家出版社呢?
> 真是個振奮人心的好消息.
預計 4/6 全部完稿, 如果順利, 希望兩個禮拜左右問市吧.
尚未認證通過
: : 我的看法剛好和您相反
: : VC使用的人太多了....所以我不去碰很多人都會的東西...
: : 而且技術性也不高...難學又低階(複雜度倒很高)
: : ...而且苦幹實幹MFC多年的老鳥也很多
: : 去跟這些人在MFC上爭高下
: : 輸了贏了都沒有什麼意義
: 哈哈...好奇怪的想法
: 我也不喜歡碰很多人會的東西
: 但是我覺得 MFC 本身只是工具罷了, 技術性當然不高
: 你該擔心的是用 MFC 寫出來的程式技術性高不高吧??
: 至於 Ap Framework, 則當然要選比較多人會的
: 這樣才比較容易跟人家合作工作嘛
: 不過這是個人選擇啦...
bios老弟的確說的也很正確:)
也反映了某種事實....
不過我的看法與經驗是這樣的
除非薪水真的很多(公司靠這套軟體賺很多錢)
或者Domain Knowledge非常有看頭
不然要我再花個一兩年好好coding MFC.......
算了.....自願放棄.....:Q
其實使用VC這個工具而不使用MFC來做GUI時
VC實在也算是不錯的工具:)
但若kernal code真的不必牽扯到GUI時
我還是會偏向使用C++ Builder
主要的原因是我可以利用BCB的GUI
來建製詳細而複雜的Debug功能.....
使用VC來開發程式的時候
若不想碰MFC
最討厭的一點是當要Dump debug information或Output時
要嘛就是利用DebugWindow,要嘛就是利用consolmode來看
都不是很方便,而且不容易分類,紀錄,整理...
但若利用C++ Builder
可以把各式各樣的debug information, status information, output等
送到各式各樣的元件
這對於根據這些資料來分析程式正確與否,實在很方便...
只要kernal code和VCL程式切的乾淨
這些kernal code還可以移到其他的compiler下重新compiler就可以了...
一點經驗談:)
囉唆一下...
david
> ==> 在 moga@cis_nctu (不像學生的學生) 的文章中提到:
> > 哪家出版社呢?
> > 真是個振奮人心的好消息.
> 出版社是 Pearson 培生, 也就是 Addison-Wesley 與 Prentice 合併後的那家公司.
> 如果一切順利... :q
呵呵天下蒼生有福了, 很感謝william來替大家把design pattern翻成
中文. 我最近實在太忙了, 不曉得已經發生這麼多事了.
記得出來時要通知大家一聲, 我一定會跑去買一本
柯仁傑
--
[1;32m※ Origin: [33m交大資工鳳凰城資訊站 [37m<bbs.csie.nctu.edu.tw> [m
[1;31m◆ From: [36m16.c210-58-152.ethome.net.tw [m
cview2000
> ==> 在 cview2000@cis_nctu (cview2000) 的文章中提到:
> 已全部改成 UML, 不過會在附錄 B 加些註解簡介兩者的不同.
真好,雖然說我原著已經看過兩三遍了,前一陣子也才得到大陸簡體
版的電子書,不過 william 大大譯的,應該可以買才是....:)
對了,不過講到中譯本我就生氣,上次我買的 Applying UML and Patterns
by Craig Larman 中譯本,印刷真是爛透了,有好幾面是兩面印在一起,
還缺頁勒,所以如果不是有"信譽"的譯者,我還是寧可多花點錢買原文書,
尤其是像 design pattern 這種經得起時間考驗的書.
cview2000
> ==> 在 cview2000@cis_nctu (cview2000) 的文章中提到:
> > 對呀 ... 原著 OMT 的圖會不會加 UML 的版本呢 ?
> 已全部改成 UML, 不過會在附錄 B 加些註解簡介兩者的不同.
真好,雖然說我原著已經看過兩三遍了,前一陣子也才得到大陸簡體
版的電子書,不過 william 大大譯的,應該可以買才是....:)
對了,不過講到中譯本我就生氣,上次我買的 Applying UML and Patterns
by Craig Larman 中譯本,印刷真是爛透了,有好幾面是兩面印在一起,
還缺頁勒,所以如果不是有"信譽"的譯者及出版社,我還是寧可多花點錢
買原文書,以免到時候買了中譯本還要再去買原文的來當"對照組".
cview2000
> ==> 在 cview2000@cis_nctu (cview2000) 的文章中提到:
> > 對呀 ... 原著 OMT 的圖會不會加 UML 的版本呢 ?
> 已全部改成 UML, 不過會在附錄 B 加些註解簡介兩者的不同.
真好,雖然說我原著已經看過兩三遍了,也嘗試著將幾個比較簡單的
pattern 應用到日常的程式寫作上,前一陣子也才得到大陸簡體
cview2000
> ==> 在 cview2000@cis_nctu (cview2000) 的文章中提到:
> > 對呀 ... 原著 OMT 的圖會不會加 UML 的版本呢 ?
> 已全部改成 UML, 不過會在附錄 B 加些註解簡介兩者的不同.
真好,雖然說我原著已經看過兩三遍了,也嘗試著將幾個比較簡單的
pattern(e.g. Factory , Singleton , Command 等) 應用到日常的
程式寫作上,前一陣子也才得到大陸簡體版的電子書,不過 william
大大譯的,應該可以值得一買才是....:) 對了,不過講到中譯本我
就生氣,上次我買的 Applying UML and Patterns by Craig Larman
中譯本,印刷真是爛透了,有好幾面是兩面印在一起,還缺頁勒,所以
如果不是有"信譽"的譯者及出版社,我還是寧可多花點錢買原文書,
以免到時候買了中譯本還要再去買原文的來當"對照組".尤其是像
cview2000
> ==> 在 cview2000@cis_nctu (cview2000) 的文章中提到:
> > 對呀 ... 原著 OMT 的圖會不會加 UML 的版本呢 ?
> 已全部改成 UML, 不過會在附錄 B 加些註解簡介兩者的不同.
真好,雖然說我原著已經看過兩三遍了,也嘗試著將幾個比較簡單的
pattern (e.g. Factory , Singleton , Command 等) 應用到日常的
cview2000
YRH
真的就很嚇人，因為MFC多了太多「雜七雜八」的東西，
基本上MS應該會放棄MFC了，所以在學的學子，應該不需要再刻意學MFC
學MFC倒不如好好研究C＋＋來的有用，
不過就我這陣子，面試的結果，業界清一色還是使用MFC跟VC＋＋
用BCB的反倒不多，寫資料庫的大多是用VB或是DELPHI（VB大宗）
> : 我是不太清楚新架構.NET和MFC的關係...
.NET跟MFC基本上已經是不一樣的東西了！
所以，我覺得不用學MFC了，要學不如學VCL或是CLX，起碼
Borland還發展得很積極。
YRH
> 反觀 MS, VC++ 一直沒有好的元件架構支撐；
我同意！MFC應該是快不用了，（五年後步上OWL後塵）
> ATL 只能算小兒科, COM/ActiveX 又不能算是專為 VC++ 而打造...
ATL其實是為了精簡化COM的設計，期使能產生網路下載小巧
速度快的COM元件，而不是用來產生應用程式。
ACtiveX/COM基本上不走C＋＋概念，你也可以用COBOL寫COM
它是一個軟體元件設計標準，可以說是跨語言的軟體技術。
致於用.NET設計COM，將更精簡COM的設計。
不過微軟已經不主打COM這個名詞，改打.NET了
（骨子裡我覺得.NET架構是為了做出像JAVA的跨平台特點，跟
維持COM元件的易用性，的設計架構）
用C＋＋設計只是方便實作COM概念！
不過，我個人覺得用DELPHI實作COM元件也是不錯的選擇
> 兩者都沒有構築出相當於 MFC 規模的元件體系。
所以ActiveX跟COM並不是用來擴充MFC的
致於VB，基本上並不是framework，而是COM平台的使用架構
VB的程式設計，主要是一個個COM元件兜出來的程式設計概念
連form都是COM物件。
跟delphi、BCB是完全不同的概念。
我個人覺得VB是一個成功軟體元件概念。
君不見多少人會寫VB，VB會改，只是要符合.NET的趨勢。
jon
> 致於用.NET設計COM，將更精簡COM的設計。
> 不過微軟已經不主打COM這個名詞，改打.NET了
> （骨子裡我覺得.NET架構是為了做出像JAVA的跨平台特點，跟
> 維持COM元件的易用性，的設計架構）
> 用C＋＋設計只是方便實作COM概念！
不懂你在說什麼 .net 和 COM 根本是兩回事..COM 尋求的是 binary standard
.net 架構則是先 compile 成 MSIL, 再經由 JIT compiler 變成 managed
native code 透過 CLR 執行. 是可以用.net component 包成 COM 物件..
不過根本是沒有必要的.
--
[1;32m┌───── [33m◆ [37mＫＫＣＩＴＹ [33m◆ [32m─────┐ [34m┐┌┐┐┌┐┌─┐┌┬┐┌┬┐┐ ┌ [m
[1;32m│ [31m bbs.kkcity.com.tw [32m│ [37m├┘┐├┘┐│ │ │ └┬┘ [m
[1;32m└── [34m《 [0;37mFrom:211.23.128.14 [1;34m》 [32m──┘ [36m┘ ┘┘ ┘└─┘└┴┘ ┴ ┴ [m