最近網路上興起一道 "Visual C++ 與 C++Builder 孰優孰劣的討論", 其中可以看到
一些頗為中肯的言論：
發信人: [email protected] (Dadai), 看板: programming
這兩個東西都蠻好用的. 但是現在我摸了幾個月之後, 我反而比較喜歡 VC++.
VC++ 的界面看起來繁瑣, 但是真的用心花個幾天把 VC++ 的功能摸熟, VC++
用起來還蠻順手的. 再加上把 VC++ 的 Application Wizard
的來龍去脈搞清楚, 把 ClassWizard 的用法弄懂, MFC 一點一點慢慢弄熟之後,
VC++ 的功能還蠻強大的. 加上 VC++ 的 HTML Help 比 BCB 好上百倍,
我現在覺得 VC++ 比較好用.
其實這兩個工具, 一個是倚天劍, 一個是屠龍刀, 放在不會用的人,
那一把都不順手. 這兩個工具都需要相當好的 C++ 基礎. 好的 C++ 基礎對
MFC, OWL, VCL 來說都是基本功而已. 學程式學了一陣子, 覺得 MFC
摸熟之後, construct 界面不比 BCB 來的慢,
重點在於界面之下你到底要如何解決問題. 這個問題比 Application
Framework 及那一套開發工具比較好來的重要多了.
====================================================================
發信人: [email protected] (四眼的王蟲), 看板: programming
Borland 在這一方面一直沒有甚麼進步, 有時候我用 Delphi 或
BCB 時還會執行 VC++ 就是要用 VC++ 的 help 系統, Borland
實在應該在這一方面大力改進才是.
界面方面 MFC 實在是比不上 VCL, 簡單的界面還好複雜一點的
MFC 就得搞上老半天.
====================================================================
發信人: [email protected] (Dadai), 看板: programming
VC++/MFC 的 Learning Curve 看起來比較長, 但是值得.
因為你如果搞懂的話, 再配合上一些 SDK 的 knowledge 及合適的 development
kit, 你幾乎可以在 Windows 下做任何你想做的事
(剩下的只是你怎樣解決你要解決的問題). 我自己覺得 MFC 要用的有點基礎,
最起碼你要能把 VC++ Wizard 能做的東西知道如何全部用手工打造出來.
不然用 Application Wizard 建出來的東西, 你一樣看不懂,
更不要講如何去改它了.
其實像 BCB 這種 RAD Tool 要學的好, 我覺得比 MFC 還難.
因為在那漂亮界面下的底層機制往往比 MFC 複雜許多. 真的大聲喊 BCB
好簡單的, 我只看到兩種人. 一種是在 Win32 SDK 裡面打滾多年, 那幾千條
Win32 API 就算沒用過也都大概摸過, 沒摸過也知道大概會叫什麼名字,
該往那邊找. 問他一個問題, 腦袋裡面會自動列出一堆 Win32 API,
一條條過濾該如何解決. 寫 Windows 程式可能打字到手指頭都長肌腱炎了.
BCB 對他們是種解脫, VCL 更是不成問題.
而另一種則是完完全全的初學者. 用 BCB 來學 Windows Programming.
最多只能學到 Compnent 有提供的功能都會用, component 不會的他也不會.
component 不行的他也不行. component 的限制就是他的限制. AP 寫到一半,
中間要 call Raw WIN32 API, 他大概就掛了. 要做現有 component
做不到的功能? 那你要不要花錢買 VCL library?
====================================================================
同樣是 RAD Tool 的使用者, 有的是全然解脫, 輕巧駕御 RAD, 大部分卻屬於陣日搜
索元件, 侷限於別人製作的元件功能內的 RAD enabled-expert, 你願當哪種人 ?
以大局觀 Visual C++, C++Builder 及 Delphi 這三套工具, 就最重要的差異來列出
以下這張表：
Visual C++ C++Builder Delphi
設計公司 Microsoft Inprise Inprise
前端語言 C++ C++ Object Pascal
Application MFC VCL
Framework
介面設計方式 傳統 RAD
(Class Wizard 及 (拖拉點按)
手工打造)
程式核心 手工打造 手工打造
(有許多程式庫及 (有許多元件, 程式庫及類別可供運用)
類別可供運用)
運作原理 呼叫 Windows API 呼叫 Windows API
--------------------------------------------------------------------
呼叫由 kernel32.dll, user32.dll 及 gdi32.dll 三大模組為首所提供的數千個
Win32 API, 原本是 Win32 應用程式開發者唯一可用的方式, 這些 API 分成幾些
種類, 各擅其職, 只要利用它們, 少有做不到的事, 唯一的缺點是, API 多且繁雜,
而且如同 RISC CPU 的指令, 每一道 API 所做的事情並不多, 往往一些必須頻繁
撰寫的例行公事, 例如建立新視窗, 註冊視窗類別, 更改按鈕顏色等等動作, 還得
花上十幾行程式碼來做, 麻煩透了。需求乃創造之本, 於是程式庫出現了, 緊接著
挾著物向導件的優點類別庫也出現了, 最負盛名的兩套就是 Microsoft 的 MFC 及
Borland 的 OWL。慢慢地, 雖然有類別庫及 wizards, experts 的輔助, 仍有人不
知足地想要發展能夠更快地開發應用程式的方法, 於是就有了 Visual Basic 這類
可靠滑鼠完成大部分介面設計工作的 RAD 開發工具, 最後才是 Delphi及C++Builder。
隨著時間的腳步, 人們總要適應大環境的變遷及進化, RAD 的確為程式開發員省下
不少介面開發的時間, 但相對地來說, 它也降低了程式設計的門檻, 太多的初學者
沈溺於 RAD 元件的強大及使用, 不知有程式語言之重要, 無論底層的系統呼叫。
我想這也許是 RAD Tool 開始受到部分人們的質疑之故。
看透非 RAD Tool 及 RAD Tool, 抹穿 MFC 及 VCL 這兩套 application framework,
它們只是包裝一薄一厚, 用法各異罷了。MFC 薄薄的一片, 讓你擁有全盤掌握的滿足,
相對地, 學習曲線既陡峭且高峻, 需有足夠的背景知識才能充份融入 MFC, 享受它的
好處。VCL 包裝地並不徹底, 但厚厚地這一層, 讓人完全看不到骨子裏的究竟, 如同
寒流一來, 一個身穿五六件襯衫外加夾克兩條的女人打從你眼前走過, 天知道究竟是
蛇腰豐臀亦或骨瘦嶙離呢。就介面打造來說, VCL 包裝的真是好用方便, 不過常有
VCL 力有未殆, 包裝不足時, 此刻, 是 RAD 也好, 非 RAD 也好, 任何工具幫不上忙,
只有瞧自己琢磨 API 的功夫, 若沒有三兩下功夫, 馬腳隨著framework的不足就立即
露出了。
相對地, 學習曲線既陡峭且高峻, 需有足夠的背景知識才能充份融入 MFC, 享受它的
好處。VCL 包裝地並不徹底, 但厚厚地這一層, 讓人完全看不到骨子裏的究竟, 如同
寒流一來, 一個身穿五六件襯衫外加夾克兩條的女人打從你眼前走過, 天知道究竟是
蛇腰豐臀亦或骨瘦嶙離呢。就介面打造來說, VCL 包裝的真是好用方便, 不過常有
VCL 力有未殆, 包裝不足時, 此刻, 是 RAD 也好, 非 RAD 也好, 任何工具幫不上忙,
只有瞧自己琢磨 API 的功夫, 若沒有三兩下功夫, 馬腳隨著framework的不足就立即
露出了。
這讓我想到幾年前曾發生的 "command line 優劣之爭", 有些高手們及UNIX fans
喜愛命令列, 一來速度快, 二來有全盤掌握的感覺; 而另一派當然是傾向 GUI 囉。
傳統確實有傳統獨到之處, 否則為什麼在電子音響大行其道的今日, 仍有玩家願意
傾幾十倍的價格, 把玩真空管音響呢 (我老爸就是一個:p) ? command line 用得熟,
操作速度比 GUI 還來得快上幾倍倒是真的, 我覺得這是 command line 需要存在的
最大理由。也有人對我說, "command line 較讓人懂得電腦真正的運作原理", 我告
訴他, "為什麼 GUI 就會妨礙到我們去瞭解電腦的運作原理呢 ?" 守舊也得要合理的
理由, 否則只是戀舊, 潛意識裏的觀感其實是怕跨入新的領域而失一向保有去優勢。
所以呢, 手工打造的好, 還是拖拉點放的方便 ? 手工打造的快, 還是拖拉點放的省
事 ? 我想是答案是很明顯的, 寧可在例行公事上能省時間就多省點時間精神, 我們
還有未來等著去創造呢, 焉可鎮日沈迷在手工打造全盤掌握之感覺中呢 ? 我想,
RAD Tool 無罪, 它只是讓門檻變了低, 讓程式設計變得簡單輕鬆, 何罪之有！
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.105.58.3