CSDN博客

img Raptor
博客专家

C++ BuilderX的问题与展望(1,问题篇-上)

发表于2004/1/15 14:03:00  3158人阅读

C++ BuilderX的问题与展望

 

猛禽[Mental Studio]

http://mental.mentsu.com

(之一,问题篇-上)

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

 

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

就现在的情况来看,Microsoft已经是铁了心要把Windows操作系统向.net上转移,未来的Windows操作系统将不再提供新的Win32API,而会以.net的方式提供。原来的Win32API也只是为了兼容性而保留。这很像当年从MS SQL 6.5MS 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#BuilderSidewinder),C++BuilderXTomahawk),JBuilderXReveille)以及刚刚在BorCon2003上发布的Delphi8Octane)。从表面上看,除了C#Builder是全新推出的与MicrosoftVisual Studio.net 2003竞争的产品以外,其它的似乎都是原有产品的延续,特别是Delphi 8延用了Delphi的产品名称,而继JBuilder9之后推出的JBuilderX的那个X也很容易被理解为罗马数字的“10”,那么C++BuilderX是否会是C++Builder 7呢?为什么不叫C++Builder 7C++BuilderVII而要叫C++BuilderX?会不会是传说中的Borland Studio甚至是Galileo的原型呢?

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

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

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

 

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

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

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

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

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

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

 

(待续)

0 0

相关博文

我的热门文章

img
取 消
img