最近网路上兴起一道 "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