编程是一门艺术

raptor.zh(at)gmail.com Creative Commons License
本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。

archives 存档

01 Jan - 31 Dec 2018
01 Jan - 31 Dec 2017
01 Jan - 31 Dec 2016
01 Jan - 31 Dec 2015
01 Jan - 31 Dec 2014
01 Jan - 31 Dec 2013
01 Jan - 31 Dec 2012
01 Jan - 31 Dec 2011
01 Jan - 31 Dec 2010
01 Jan - 31 Dec 2009
01 Jan - 31 Dec 2008
01 Jan - 31 Dec 2007
01 Jan - 31 Dec 2006
01 Jan - 31 Dec 2005
01 Jan - 31 Dec 2004
01 Jan - 31 Dec 2003
01 Jan - 31 Dec 2002
01 Jan - 31 Dec 2001
01 Jan - 31 Dec 2000
01 Jan - 31 Dec 1999

--

links 链接

--

C++ BuilderX的问题与展望(全文)

写这篇文章的初衷源自2003年12月11日在玉笛书生兄所建C++Builder的QQ群中,与书生、令狐虫、ccrun等几位BCB版的老朋友的一次聊天(聊天记录见《一次关于C++BuilderX的讨论》)。 主要就是聊了一下BCB/BCBX的现状以未来可能的发展方向,因为觉得对各位用BCB的朋友也许有帮助,故在令狐兄的支持下,整理成文。本文的内容如题 目所言,先说说BCBX现在的问题(包括Borland在此次产品转型中的一些不太合适的做法),然后就我们几个的个人观点来谈谈对它的展望虽然说是 BCBX的展望,当然这些都是我们的一些一孔之见,Borland未来会怎么做,那是由不得我们的。

两年多以前我曾经设想Borland会推出一个高度集成的开发工具,我当时称之为Borland Studio(参见拙作《Borland Studio?》), 后来又听李维说,Borland正在研发的代号为Galileo的开发工具将是一个比我设想的Borland Studio更为强大的东东。然而很不幸,所谓计划没有变化快。时至今日,这些东东终成泡影,不知道什么时候Borland才能给我们这样的惊喜。(补 充:现在看来似乎又有一点希望,C#Builder是BDS1,Delphi8是BDS2,这个BDS据说便是Borland Develop Studio,也许BDS3会给我们一个惊喜吧)

就现在的情况来看,Microsoft已经是铁了心要把Windows操作系统向.net上转移,未来的Windows操作系统将不再提供新的Win32API,而会以.net的方式提供。原来的Win32API也只是为了兼容性而保留。这很像当年从MS SQL 6.5向MS SQL 7.0迁移的情况,在MS SQL 7.0中的DBLIB只提供与6.5兼容的部分,新增功能都是以OLE-DB方式提供,而到了MS SQL 2000时,DBLIB几乎已经不能用了。MS SQL的这次转移成功地实现了一次飞跃,并完全摆脱了Sybase的阴影,所以Microsoft在.net中应该还是会故伎重演的。

在 这种情况下, Windows平台下的原生开发工具日渐式微,这对于Borland来说,无疑是要作出重大的抉择。所以Borland在今年(2003年)先后推出了四 个主要产品:C#Builder(Sidewinder),C++BuilderX(Tomahawk),JBuilderX(Reveille)以及刚 刚在BorCon2003上发布的Delphi8(Octane)。从表面上看,除了C#Builder是全新推出的与Microsoft的Visual Studio.net 2003竞争的产品以外,其它的似乎都是原有产品的延续,特别是Delphi 8延用了Delphi的产品名称,而继JBuilder9之后推出的JBuilderX的那个X也很容易被理解为罗马数字的“10”,那么C++ BuilderX是否会是C++Builder 7呢?为什么不叫C++Builder 7或C++BuilderVII而要叫C++BuilderX?会不会是传说中的Borland Studio甚至是Galileo的原型呢?

所谓希望越大,失望也越大。当C++BuilderX还在测试版阶段时,许多C++Builder用户都迫不及待地下载了Tomahawk来先睹为快,我也一样,但结果却令人大失所望。这在BCB用户群中造成了极大的反响,其中比较有名的就有如CSDN BCB版的Aweay兄的文章《Borland听我对你说》等。

虽 然Borland中国的左轻侯很快就撰文为BCBX作了一番辩解,但还是难以令人接受。BTW:按左兄的说法,Galileo已经成了Borland在. net平台下的开发工具(C#Builder和Delphi8)所用的统一的IDE的名称,看来是不用对Borland Studio抱什么希望了。

不可否认Borland在C++开发工具中的这次转型从未来发展的角度上说是必要的,也是正确的做法,具体请参见左兄的文章(《关于Borland C++BuilderX的一些问题的回答》 或《程序员》2003年第十二期)。但还是要指出Borland在此次转型中的错误做法及可以改进的方面。我们几个虽然不能说代表Borland的用户, 但至少也算是Borland的铁杆用户,我们的意见应该来说还是比较有代表性的,可以毫不夸张地说:如果Borland不能在未来作相应的改进,恐怕是难 有机会在C++领域里再翻身了。

首先说说BCBX推出的方式是非常不合适的。最主要的就是没有提供一个从BCB到BCBX的平滑过渡。Borland一向标榜自己的特色是:为客户带来新技术,创造新价值,同时保护客户已有投资。过去她也一向是这么做的,然而这一次却没有做到。这是一个非常严重的错误。

从历史上说(参见李维的《Borland传奇》 一书),这种错误Borland曾经犯过多次,每一次都是造成用户的大量流失。以C++开发工具为例,第一次发生在BC4的OWL2与BC31的OWL1 不兼容,加之BC4本身品质不佳,造成Borland用户的第一次大规模流失,这次事件最终使Borland从一流的软件公司堕落成为二流的软件公司。虽 然后来推出了相当不错的BC451,然而已经为时太晚,回天乏力。直到BCB的出现,作为第一个RAD C++工具抢回了一部分用户,然而由于种种原因(其中一个当然是因为BCB使用的VCL让它始终笼罩在DELPHI的阴影之下),已经无法重现当年 BC31的辉煌了。

让 人无法想象的是Borland在花了这么大的代价买来的教训,却还不知吸取,才过了不到十年,再次犯同样的错误。当我第一次看到BCBX时的感觉就像若干 年前第一次看到BC4或BCB1一样:起初是新鲜,大喜,接着就是失望(完全是中看不中用),然后开始盼望下个版本能解决(当然这两次都盼到了,一个是 BC451—可惜来得太晚了,另一个是BCB3—这个比较好玩的就是,当时我们都在盼望的是BCB2,结果却盼到了BCB3,大概是Borland为了和 Delphi的版本号一致,跳过了BCB2)。

其实Borland要避免这种窘境并不困难。有两个方法:一个 是在BCBX中暂时嵌入一个BCB的IDE的简化版,让它能继续支持VCL的RAD开发,因为对C++开发工具来说,即使在开始时牺牲少量的跨平台特性 (BCB是不能跨平台的),问题并不大,因为这部分特性本来就是为了继承Windows平台下的东西,更何况像Jbuilder这样对跨平台要求很高的产 品,在早期版本里一样不是纯JAVA的;另一个方法就是像DELPHI那样,提供一个BCB7作为过渡。因为从某种角度上说,Delphi7对 Delphi6的改进,实在是非常之少,所以有人戏称Delphi7其实是Delphi6.5。就现在的情况来看,Delphi的转型无疑要比BCB成功 得多,Delphi8提供了.net开发和兼容VCL开发(通过VCL.net)。而从BCB的情况来看,唯一的解释就是Borland对BCB不够重 视。其实在这两个方法中,个人认为后面一个方法更好一些。因为虽然现在.net大行其道,但可以肯定是的Windows下的原生开发还要持续几年,在这段 时间里让BCB7和BCBX并行(因为在大多数情况下,二者的冲突不是很大)对Borland占领C++开发工具领域非常有利,而且有一个BCB7这样一 个填补这个空白的产品(因为那时大多数开发工具都到.net下了)还能带来一定的收益。

虽然说Borland作为一个不能算太大的公司,没有足够的资源维持一条过长的 产品线,如果要在BCBX中加入BCB或同时开发BCBX和BCB7,会有困难。但作为一个全新领域的产品(在平台中立的C++开发工具中,暂时还没有像 BCBX这样的产品,即使是传说中的Eclipse+CDT,也暂时不能成什么气候),略为延后一些发表并不会造成太大的影响,反而是推出不够成熟的产品 会造成严重的反面后果,在这点是Borland也是吃过大苦头的,最典型的莫过于Delphi4。而且如果有BCB7作为缓冲的话,BCBX的延后发表, 对市场来说也不会有太大的影响。

但是现在Borland已经这么做了,要想挽回的话,只有在产品上作文章了,这样反而把Borland自己逼上了一条无法回头的路了—必须尽快推出一个“可用”的BCBX。而这个“可用”的要求就要比通过BCB7缓冲后要高得多了。

然后来具体说一下BCBX这个产品。

它 不能说没有优点,先从IDE说起吧。BCBX采用了一个全新的IDE—PrimeTime,这个IDE来自于JBuilder,而且后来的 JBuilderX也是采用这个IDE(只是在JBuilderX中用的新版本PrimeTime具有更多的优点,如代码折叠等)。这个JAVA写的 IDE可以跨平台,看上去也很美,使用上虽然与BCB/DELPHI不太一样,但至少还是保持了Borland的一贯风格,特别是对JBuilder用户 来说会很自然。

这个IDE除了具有BCB原有的一些特性,如Code Template等功能以外,特别值得一提的是,它还具有原来在BCB上没有的版本控制功能(见Editor的History页面),这个功能我前两年就 在JBuilder上看到了,眼馋的不行,现在终于也可以在C++中享受到了。此外它还可以像JBuilder一样集成多种源码版本控制工具(CVS, ClearCase,VSS)。

对于编辑器,BCBX还有一个很好用的功能就是Sync Edit,通过选择一段文本,可以方便地修改其中相同的标识符等,在进行代码重构时非常有用。

还有就是提供了一个类似Class Explorer的Structure View功能,可以在这里立即跳转到各个类/函数的定义或实现处。另外它的Editor支持嵌入源码的ToDo Item功能,并且能在Structure View中立即显示出来,而且也可以从Structure View中跳转,比BCB中的ToDo List功能要强大。

另外,对Project的管理功能也略有加强,可以定义和调整Project Group中的编译顺序(相当于一种Project依赖关系)。这一点也是BCB曾经被人垢病的一个方面。

BCBX 还有一个特性是与BCB一样的:支持基于VisiBroker的CORBA应用开发。特别是它比BCB有一个很大的改进,在BCB中用CORBA向导默认 生成的CORBA应用是使用BOA的,而这是早在五年前就被CORBA2.2规范制定的POA所代替了(当然BOA也可以用,但基于移植性考虑,OMG建 议使用POA),在BCBX中终于用POA代替了(而且好像不能再用BOA了)。

至于很多人认为BCBX这个 用JAVA写的IDE速度太慢,我倒不觉得,只是启动速度略有些慢,不过BCB的启动也不能算很快,比起VS.net来说慢太多了。也许是因为我的机器内 存比较大的缘故,虽然是PIII-733的CPU,但有512M内存。看来要跑BCBX要先准备好内存了。

BCBX除了这些IDE方面的好处外,还有一个好处就是带有dbExpress这个跨平台的通用数据库访问技术,所以用BCBX做跨平台数据库应用会比较方便,并且目前dbExpress支持的数据库种类还是比较多的。

虽然BCBX有上述的优点,但也不能改变它是一件“粗糙”的产品的本质,简直就和当年的BCB1如出一辙。

首 先最大的败笔莫过于不支持VCL了。据说不支持VCL还有理由了:因为它的目标用户不是BCB用户,而是更为广大的非VCL的C++用户,如其它平台的C ++用户及VC的用户等,VCL是BCBX2的目标。而且不支持VCL就算,也没有提供一个别的GUI开发的Framework,比如传说中的 wxWindows(据说要在BCBX2里提供)。

其次来说这个IDE,作为IDE技术的发明者, Borland应该很了解开发人员要的是一个什么样的IDE,它应该能够在其中很方便地完成大部分的开发工作,但BCBX明显达不到要求。虽然它带有很多 BCB不支持的功能,但同样的,有很BCB中具备的功能,在BCBX中还没有提供。特别是非常重要的Code Insight功能居然都没有,而且它的Structure View,虽然在某些方面比Class Explorer强大(如ToDo),但它的功能还是太弱,比如不能在Structure View里创建类成员等。还有BCBX的Editor中不支持跳转到定义的功能,不支持Open file at cursor等。而且个人认为BCB6中将只将单元放在Editor上面的Tab中,而将CPP文件和H文件放在下面的Tab中是一个好办法,但BCBX 却还是像BCB5一样都放在上面,这样文件一多就要卷来卷去。

还有一个足以说明它“粗糙”的理由是:BUG。我曾经试过在一个很简单的应用里只是更换了一下编译器,正要保存设置时,IDE无响应,CPU占用100%。

其实Borland提出BCBX这个策略是没有错的,只是策略的实施上有些问题。

BCBX 的产品定位是定位于非VCL的C++用户。在这点上,就会让Borland目前的C++产品用户,基于VCL的BCB用户非常不满,特别是没有提供像 BCB7这样的过渡产品,可能导致用户流失。其次,对于非VCL的C++用户来说,也未必吸引人。这部分C++用户主要有两派:一派是用VC的用户,一派 是用GNU C++的用户。对VC用户来说,跨平台特性对他们完全没有吸引力,而在Windows平台下,VS.net还是非常好用的,并且他们可以很方便地进行. net应用开发,BCBX提供的多编译器支持对他们来说也是没用的功能,所以在这里BCBX基本上没有什么市场。

估 计BCBX更主要的目标市场在GNU C++。用GNU C++的用户中,很大一部分是开源社团,而对他们来说,根本不屑于使用像BCBX这样的东东,特别是自从Danny.Thorpe当年因为开发 Kylix,与Linux社团有一次大的冲突,Borland在开源社团的影响并不好。而且就BCBX本身来说,它虽然说支持ACE、Boost、 Loki这些库,但是事实上这些库本来就是通用库,支持很多的编译器,其中也包括BCB,所以这根本不能算什么特性。而且虽然BCBX对Project管 理功能有所增强,但比VS.net还有差距,更别提跟开源社团习惯使用的Make文件相比了(虽然Make文件用起来比较复杂,但对于大项目来说,它是最 好的解决方案,即使是项目管理功能好如VS.net,跟Make文件相比还是差得太多了)。

纵观整个 BCBX,其中提供的有价值的东西非常有限:一个是还不能算是很完善的IDE,另一个可能就算是dbExpress了。至于像CORBA向导之类的并不算 很特别,用命令行编译IDL一样可以实现它的功能,虽然没有向导那么方便,但更加自由,不用受制于VisiBroker,可以选择各种ORB产品。版本控 制也可以用CVS等专门的软件,只是要多一些手工操作,没有集成起来这么方便而已。其它像编译器一类的更没什么好说的,BCBX还是用的BCB6的编译 器:BCC5.6。BCBX集成了Together(据说,我用的Enterprise版是没有的)却没有提供相应的企业应用开发的 Framework,,如C#Builder/DELPHI8中的ECO,或是像BCB/DELPHI那样的MIDAS/DataSnap。

当年Kylix 1.0甫一堆出,就有人评论它是一个“玩具”,直到Kylix 3才基本有了一个产品的样子(可惜看样子它注定是要夭折的了)。然而今天的BCBX却连当年的Kylix 1都不如。

按Borland 在中国一向的产品定价,一般开发工具的企业版都是定在29950元人民币的天价(相对于MS来说完全可以说是天价,因为三万多元定一年的MSDN宇宙版, 可以得到MS的所有产品),BCBX应该也不会例外,说句不客气的话,这样乏善可陈的产品定这样一个价格真是与抢钱无异。

说了BCBX这么多的问题,该来谈谈我们的展望了。

首 先从产品定位说起。大家都知道,每种语言都有其适用的领域,没有什么语言能通吃所有的开发工作,C++也一样,虽然从某种程度上说,C++可算是目前开发 领域最广的语言,几乎可以用于绝大多数的应用或系统的开发,但在不少情况下,它仅仅是“可以”而已。比如在企业应用开发领域,C++并不是一个很好的选择 (虽然借助于VCL,BCB基本上做到了),但通常选择Java或.net可以更快更好地解决问题。

就目前情 况来说,C++最常用的开发领域有两个大的方面,一个是系统级应用开发,如操作系统,驱动程序(这两种应用更主要的是用C和汇编,但也有部分可以用C+ +),编译器,虚拟机,工业数据采集,通信,系统服务等;另一个是一般应用开发,主要是指非企业应用或者说是非数据库应用方面,如一般GUI应用程序,工 具软件,图像处理,多媒体等(虽然这些应用有些也可以用.net等虚拟机技术开发,但是在一些关键性部分基于性能上的要求,还是需要C++等原生开发语言 的)。

基于这些原因,作为定位于通用C++开发工具的BCBX要想在C++开发工具领域占有一席之地(暂且先不说它是不是有希望重振当年BC31的声威),就应该结合C++语言的实际情况,这两方面的应用开发上有独到之处。。

首 先说系统级应用开发。对于系统级应用开发来说,GUI通常不是很重要的方面,它对开发工具的要求更侧重于性能和调试等方面。即要求编译器能生成高度优化的 代码,并且目标程序要很稳定,要提供方便的底层调试功能。而且一般这样的软件都相对比较庞大,对项目管理的要求比较高。

对 应这些要求,未来的BCBX应该加强在编译器,调试器及项目管理方面的功能。比如在编译器方面,现在BCBX用的BCC5.6是肯定不能满足要求的,虽然 BCBX支持使用其它的编译器,但作为一个完整的开发工具而不仅仅是一个IDE,BCBX中不能没有Borland自己的编译器。不过据说Borland 正在开发一个全新的跨平台C++编译器—BCCX,让人拭目以待;在调试器方面,这曾经是Borland的强项之一,现在已经没落了,不过也可以考虑跟别 的公司合作或通过集成第三方产品来实现;至于项目管理一直是Borland的弱项之一,而且对这样的复杂项目来说,即使实现了像VS.net那样的管理还 是不够的,这个可以考虑提供一个MakeFile管理工具来实现,毕竟这方面的应用还是MakeFile最好,但它的编写维护都是比较麻烦的,如果能提供 一个能生成MakeFile的向导及一个能方便地管理MakeFile的工具,也是相当不错的。

再来看一般应 用开发。对于这方面的应用开发来说,一个好的GUI开发工具是非常重要的,此外对编译器,调试器,项目管理同样也有一定的要求。因为这类应用的最终用户通 常都是一般电脑用户,不同于系统应用面对的都是专业用户,所以对界面要求通常都很高,不但要通做出标准的GUI界面,常常还需要能实现一些花哨的界面功 能。这就对GUI Framework提出了较高的要求:它不但要好用,简单,还要能很方便地扩充。VCL就是一个很好地实现了这个要求的GUI Framework,但是很遗憾的是,它不是跨平台的,虽然后来Borland又推出了跨平台的CLX,但是它用基于QT库的,而QT库的License 对商业应用不是免费的,这又限制了CLX的应用,特别是现在Borland已经暂停(也许是停止)了Kylix这条产品线,对CLX来说无异于雪上加霜。

既 然VCL和CLX两条路都走不通,BCBX未来唯一的出路就是采用一个新的GUI Framework,目前看来Borland是会选择wxWindows。但这带来了一个问题:因为BCB的产品线已经停掉了,BCBX未来必须接下 BCB的用户,而如何从VCL向wxWindows过渡是未来BCBX面临的一大问题。不过有消息说Borland已经提供了解决方案,在新的BCBX中 将采用一个开放的GUI Desgner,支持多种GUI Framework,已知的就有wxWindows和JavaBean,而对于非跨平台的VCL,在新的BCBX中将通过一个被称为“VCL Bridge”的东西实现。这样看来,在未来的BCBX中将能比较完美地实现这一功能。

再来看企业应用开发。虽然就目前的情况看,基于虚拟机平台的开发技术(JAVA或.net)已经成为企业应用开发的主流,而C++不是一种适用于虚拟机的语言(虽然MS将所谓的Managed C++加入.net,但情况不并好,不过C++适用于开发虚拟机倒是真的),无论在开发效率和产品品质方面,用C++做这方面的应用都是不合算的,即使是在产品性能方面,C++所能取得的优势也日趋减少。

但 是这个市场仍然存在。首先,在一些情况下,企业应用系统还是需要和一些底层应用(如硬件驱动或其它原生代码程序等)进行交互,这时用基于虚拟机的技术并不 方便(.net相对做得较好);另一方面,则是在一些对性能有较苛刻要求的应用中,用基于虚拟机的技术可能不能满足要求。这也就是为什么像BEA的 TUXEDO这样的原生代码应用中间件仍然有相当大的市场的原因所在。

在较好的实现了满足前面两种应用的开发 要求后,BCBX也完全可以进军这一领域。对于BCBX这样一个跨平台开发工具来说,所用的中间件技术当然也必须是跨平台的, MIDAS/DataSnap所支持的COM技术是肯定不行的,而只能用JAVA开发的EJB当然也不行,唯一剩下的就是CORBA。虽然现在BCBX提 供了VisiBroker的CORBA应用向导,但相对于MIDAS/DataSnap来说,功能还是太弱。即使加上Together,BCBX距离一个 像样的企业应用开发工具还是比较远的。还有一个问题是:虽然Borland的VisiBroker(现在已经改名叫Borland Enterprise Server—BES之VisiBroker版了)曾经是全球市场占有率排名第一的CORBA产品,即使现在它也是数一数二的,然而毕竟还有很多其它的 CORBA产品可以选择,比如现在占有率第一的IONA的Orbix以及Open Source的ACE/TAO和MICO等(只考虑支持C++的)。如果BCBX不能以一种开放的姿态来接受它们,依然很难在CORBA领域取得大的成 就。

在 这一点上,Borland应该是有经验的,当年JBuilder正是因为能与BEA的WebLogic很好地结合起来,才得以取得如今的胜利。逼得IBM 不得不放弃Visual Age for JAVA(就是后来成为Open Source的Eclipse),虽然在一些方面,VAJ还是比JBuilder有优势的,并且IBM的WebSphere在各方面的表现也不比 WebLogic差,然而Borland和BEA的强强联手实在太强大了。如果当年JBuilder只抱着IAS(Inprise Application Server即现在BES的前身)不放的话,实在很难能在JAVA开发工具领域有什么大的作为,因为在WebLogic和WebSphere面前,IAS 还差得太远了。所以现在JBuilder支持的EJB Container是越来越多了,除了前面说的这些商用产品外,Open Source的JBoss也同样在支持之列。

BCBX 完全可以借鉴JBuilder的这一经验,支持集成包括IONA Orbix,ACE/TAO等多种CORBA产品开发,相对来说,这一点比集成不同的GUI Framework要容易很多,因为CORBA规范是由OMG定义的标准,不同产品之间的差异相对较小。所以问题的关键就在于Borland是否愿意这么 做了,毕竟这可能影响到BES这条产品线的市场。老实说,Borland在企业中间件市场中一直是很失败的,从早年通过收购OEC取得Entera,却很 快因为COM和CORBA的崛起而被迫放弃;通过收购VisiGenic取得了VisiBroker后,虽然在跟Netscape的合作中曾取得一定的成 功,但随着NetScape的没落,VisiBroker的领先地位也很快被IONA的Orbix所取代;后来从IAS开始做JAVA中间件,也一直是只 能在没有WebLogic和WebSphere的市场角落里分一点残羹而已。与其让BCBX的企业开发与BES一起没落,还不如像JBuiler一样牺牲 BES换来BCBX的成功,毕竟对Borland来说,开发工具才是真正的主营业务。

当 然,光有对CORBA的支持还是不够的,毕竟企业应用开发是一个大问题,需要的支持还是很多的。虽然现在BCBX有DBX这个方便的数据库访问技术,但是 还缺乏一个系统的Framework,一个类似于MIDAS/DataSnap的东西。另外要结合Together的MDA开发,还必须有一个类似于 ECO的数据持久化技术。

还有对SOAP/WebService的支持是不能少的。虽然它并不是一个像MS所吹嘘的那样,是一个万能的技术,但还是有很多地方需要它的。特别是当需要与其它应用沟通时,虽然与JAVA应用沟通可以通过RMI over IIOP,但要与.net应用或其它的应用沟通,SOAP还是一个比较好的解决方案。

有了这样一个强大的企业开发环境,就像我前一段向朋友“太可怕”(CSDNID:comanche)推荐ACE/TAO时说的:“这个世界没有MS,没有SUN,一样可以很美好。”

正 如我前面所说,现在的BCBX是乏善可陈的,然而如果未来的BCBX真的可以加入我前面所说的这些Feature,包括一个完善的IDE,一个优秀的编译 器,一个方便高效的GUI开发环境,以及一个功能强大的企业开发Framework等,那么BCBX才真正像一个Powerful的C++开发工具(让我 想起Borland当年拍的BC31广告片^_^),重拾BC31当年的风光也不是不可能的。

本来写到这里就差不多完了,不过Borland大概是为了安抚用户对BCBX的不满情绪,最近推出了一个BCBX Preview包(在Borland网站有提供下载),通过将这个包安装到BCBX中,可以大致了解一下未来版本的BCBX会是什么样子。我简单地试用了一下,所以在最后要补充一些对这个Preview的看法。

这个Preview包括两个部分:一个是集成了wxWindow的GUI开发环境,另一个是全新的C++编译器BCCX的预览版。下面分别作一个说明:

首 先来看这个GUI Designer。在IDE的New wizard里增加了两页,其中一页就是wx framework(另一页是preview),里面有两项:New wx framework project和New wx framework form。用前者创建一个新的wx应用,可以看到它生成的代码中包括一个XRC文件,这是一个XML风格的界面资源文件,类似于DFM/XFM。在页面下 部有一个Design的Tab,点击即可打开GUI Designer。

这个GUI Designer和以前的BCB的GUI Designer还是很相似的,包括控件栏,设计区和Object Inspector三个部分。其中控件栏也是在页面上方,只是控件少得多了,只有三页共18个控件。设计区和BCB不同,不再是独立的Form Design,而是像Visual Studio/Galileo那样嵌在页面里,而且控件的定位也不是用以前的八点框,而是一个蓝色的粗框,也没有Grid定位。Object Inspector也有不同,首先是位置改在页面右边,跟JBuilder一贯的风格相同,当然内容就更不同了,毕竟现在的Framework是wxWindow而不是VCL了。

再 来看BCCX编译器。同样是在IDE的New wizard里有一页Preivew,其中包括三个项目,其实这里生成的代码与Project页中的相应项目并无太大不同,只是所用的Include目录 (Preview带有一套新的Include文件和启动代码)和编译器设置略有不同而已。另外,在IDE的编译选项中也增加了一项:“Borland? C++ Compiler Preview for Windows (IA-32) Tools”。看BCCX命令行提示可以看到,它的版本信息为:Borland C++ Compiler 6.0 Preview。可见这是Borland的一个全新版本的C++编译器,同样还有与之配套的Incremental Link,也是6.0版的。

不知道是不是因为新的编译器配置有所不同,我只在IDE中编译通过很简单的程序,还未能成功编译过wxWindow应用,看来还需要再研究研究。

当 然这个毕竟只是Preview,问题还是有的。除了上面说的编译器的问题外,GUI Designer也是有问题的,最大的问题就是速度慢。在我的512M的机器上,BCBX跑起来也只占到300多M的内存,还未将物理内存用尽,但做 GUI Design时的速度却比用JBuilder做GUI还要慢上许多,这实在让人难以忍受。其次一个问题是它不支持中文,在控件的属性中输入中文会变成乱 码,估计跟XRC文件使用UTF-8编码时对中文(应该其它DBCS也有同样的问题)没有能够正确处理有关。

这篇文章断断续续写了一个多月,终于可以告一个段落了。最后还是要给Borland提点意见:Borland在2003年里出的几个产品,完成度都不算高, 其中除了JBuilderX我不是太了解以外,C#Builder、C++BuilderX和Delphi8我都试用过,基本上都未达到可用的程度。希望 今年Borland能够吸取教训,推出一个令人比较满意的BCBX新版本。

Trackback link:

Please enable javascript to generate a trackback url

No trackbacks

评论(0)


 
   
 
  表情图标 

 


提示: 除了 <b> 和 <i> 之外,其他的Html标签都将从您的评论中去除.url或mail地址会被自动加上链接.