发信人: TopazY (清凉的水罐), 信区: C++Builder
标 题: Cb & Vc 经典大讨论（很长的一篇文章！）?
发信站: BBS 水木清华站 (Thu Aug 31 12:26:49 2000)
查看问题及答案
序号 25 请对 Visual C++与Delphi/C++Builder之比较 一文发表看法
wenyy 来自 http://www.vchelp.net：
Visual C++与Delphi/C++Builder之比较
作者：紫云英
[email protected] http://jacafe.webprovider.com
如果有什么看法，请大家在在线讨论中进行讨论。
写给站长的话
“Visual C++与Delphi/C++Builder之比较”这个话题也许有些无聊，但既然网上有那
么多的人在争论这个话题，也许这样一篇文字也不是全无价值。我觉得你的网站”学术
气氛“比较浓，新开的聊天室里人们也比较友好。(也许因为大家都为了同一个目标走到
一起吧。^_^)我就把这篇可能有争议的东东发给你了。本文欢迎讨论，也欢迎批评，从
语言到内容。
正文
经常看见有朋友在CSDN等论坛发帖子问Visual C++和C++Builder这两个重量级开
发工具孰优孰劣(更多的是问Visual C++与Delphi孰优孰劣)。本文就试图从技术水平、
易用性、稳定性、发展前景等对它们进行比较分析。
由于Delphi与C++Builder同为Inprise公司产品，共享集成开发界面(IDE)，而且
使用同一套VCL框架(这一点最关键)，它们带的调试器、PVCS/TeamSource团队开发支持
、数据库引擎及企业版中集成的其它高级功能等都是相同的，所以本文将其与C++Build
er归入“同一阵线”。我在网上见到一些Delphi程序员认为C++Builder与VC比较接近，
这是个误解。事实上，Delphi和C++Builder除了使用的语言不同，其余几乎都相同。为
了避免话题转移到C++语言与Object Pascal语言(即Delphi所用的语言)的比较，下文主
要对比分析Visual C++与C++Builder。
首先，从它们的应用程序框架(Application Frame，有时也称为对象框架)进行比
较。Visual C++采用的框架是MFC。MFC不仅仅是人们通常理解的一个类库。(同样，Del
phi和C++Builder使用的VCL的概念也不仅仅是一个控件库。)你如果选择了MFC，也就选
择了一种程序结构，一种编程风格。MFC早在Windows 3.x的时代就出现了，那时的Visu
al C++还是16位的。经过这些年的不断补充和完善，MFC已经十分成熟。但由于原型出现
得比较早，MFC相比于VCL落后了一个时代。尽管微软对MFC的更新没有停止，我也经常读
到持“只要Windows不过时，MFC就不会过时”之类观点的文章，但就象Inprise(原Borl
and)的OWL框架的淡出一样，MFC的淡出也是早晚的事。如果MFC青春永驻，微软的开发人
员也不会“私自”开发出基于ATL的WTL呀。当然，WTL的地位不能和MFC比，它并不是微
软官方支持的框架，封装的功能也相当有限。但至少也反衬出了MFC存在的不足。
我以为，最能体现一个应用程序框架的先进性的是它的委托模型，即对Windows消
息的封装机制。(对Windows API的封装就不用说了吧。大同小异，也没什么技术含量。
如果高兴，你也可以自己写一个类库来封装。但对Windows消息驱动机制的封装就不是那
么容易的了。)最自然的封装方式是采用虚成员函数。如果要响应某个消息就重载相应的
虚函数。但出乎我的意料，MFC采用的是“古老”的宏定义方法。用宏定义方法的好处是
省去了虚函数VTable的系统开销。(由于Windows的消息种类很多，开销不算太小。)不过
带来的缺点就是映射不太直观。好在较新版本VC带的ClassWizard可以自动生成消息映射
代码，使用起来还是比较方便的。但和VCL的委托模型相比，MFC的映射方法就显得太落
后了。而C++Builder对C++语言进行了扩展，以便引入组件、事件处理、属性等新特性。
由于功夫做在编译器级，生成的源代码就显得十分简洁。但是由于扩展的非标准特性，
使用VCL的C++Builder的源代码无法被其它编译器编译。而MFC的功夫做在源代码级，虽
然消息映射代码较为复杂且不直观，但兼容性非常好。只要你有MFC库的源代码(随VC企
业版的光盘提供)，你的MFC程序理论上用任何符合ANSI标准的编译器均可编译通过。C+
+Builder 3以上版本可以原封不动直接编译Visual C++程序，很多人认为这是C++Build
er的兼容性好，实际上很大程度应归功于MFC的兼容性好。微软辛辛苦苦用标准方法写M
FC，却为对手制造了方便。不知他们作何感想？而因为C++Builder对语言作了扩展，VC
不能编译C++Builder的程序。看来在这方面VC要输给C++Builder了。而且VCL所支持的组
件、属性等都是MFC所缺乏的特性。虽然VC也能支持组件，但要通过AppWizard先生成一
个“包裹”类(wrapper)，不如VCL来得简洁。有很多人使用C++Builder就是冲着控件板
上那一大堆组件来的，VC虽然能使用的组件也很多(也许不比C++Builder少)，但由于不
方便而对RAD程序员没有吸引力。
C++Builder的VCL比Visual C++的MFC先进的另一个特性是异常处理。但令人啼笑
皆非的是，它的异常处理代码有bug，有时会无端抛出异常。不知道在最新的版本中有没
有改正了。而VC的框架MFC也不是一无是处。经历了那么多年的发展和完善，MFC功能非
常全面，而且十分稳定，bug很少。其中你可能遇到的bug更少。而且有第三方的专门工
具帮助你避开这些bug。如此规模的一个类库，能做到这一点不容易。不要小看了这一点
，很多专业程序员就是为这个选择VC的。而C++Builder的VCL的bug就相对较多了，而且
有些它自己带的示例程序都有错误。看来Inprise还有很长的路要走。
再从它们的易用性比较。VC有ClassWizard、SourceBrowser等一系列工具，还附
带Visual SourceSafe、Visual Modeler等强大的工具，易用性非常好。(VC自带建模工
具Visual Modeler，也许说明了它才是工程级的开发平台，与C++Builder的定位不同。
)它所带的MSDN这部“开发者的百科全书”更是让你“没有找不到的，只有想不到的”。
而且它的AutoComplete之类小功能也比C++Builder要体贴。C++Builder的新版本虽然也
提供了这一功能，但它的提示要等好几秒才出来，有时你不经意间把鼠标停在某一处，
也要等硬盘响好几秒，这可是在566Mhz的赛扬II上呀。不要笑我琐碎，有时一个开发工
具的成熟和易用，就是从这些小地方体现出来的。C++Builder作为RAD工具，理应强调易
用性。但与VC相比还显出不成熟。这是不应该的。
再来看看它们的可移植性。Inprise正在开发C++Builder和Delphi的Linux版本，
代号为Kylix。也许通过Kylix，用VCL构架编写的Windows程序向Linux移植成为可能。但
这只是可能。因为在目前Inprise的兼容性工作做得并不好。C++Builder可以编译VC程序
还要多谢微软使用标准方法写MFC，而它自己各个版本之间兼容性却不太好。低版本的C
++Builder不能使用高版本的VCL组件(这还别去说它)，而高版本的C++Builder竟然不能
使用低版本的VCL组件。真是岂有此理，我很少看见软件有不向下兼容的。如果Windows
98不能运行95的程序，Windows 95不能运行3.x的程序，Win 3.x不能运行DOS程序，你
还会用Windows吗？如果不是C++Builder的其它某些方面太出色，光是这个向下不兼容就
足以让我抛弃它。而且虽说通过捆绑编译器，C++Builder可以编译Delphi的Object Pas
cal代码，但C++Builder仍不能使用为Delphi开发的VCL组件。所以一个组件有for D1/D
2/D3/D4/D5/C1/C3/C4/C5这些不同版本是常有的事，而且随着C++Builder版本的升级可
能还会增加。希望Inprise能先解决同门兄弟的兼容性问题。而微软的VC就没有这类问题
。MFC1.0的程序也可以毫无障碍地在VC6.0下编译通过。
再来看看它们的前景吧。实际上，技术的进步在很多时候是此消彼长的。当初Bo
rland的Turbo C和Borland C++几乎是唯一的选择。微软的Quick C(现在还有人知道这个
产品吗？)和Microsoft C/C++从来也没有成为过主流。但Borland C++又流行了多少年呢
？不久就被新崛起的Microsoft Visual C/C++压下去了。现在的C++Builder又有后来居
上的态势，如果稳定性再提高一些，bug再少一些，有希望成为主流。但Inprise的总体
实力不及微软，这也是无可争议的。从C++Builder 5的Release Notes中的Known Issue
s部分，以及它们的帮助文档的规模和质量都可以看出。(哪个同类产品的帮助文档能和
MSDN比呢？)Inprise公司应从Netscape吸取教训，不要让C++Builder成为第二个Netsca
pe Communicator。(Communicator也是一度技术领先，甚至曾占据了大部分的浏览器市
场，但似乎后劲不足，而且 6.0 PR1、2中bug多多，现在被IE压得抬不起头。)C++Buil
der是Inprise的旗舰产品之一，前景应当还是比较乐观的，而且Inprise已经在向Linux
进军了，而微软还迟迟没有动作，难道非要到Linux成燎原之势(或许已经成燎原之势了
)才会奋起占领这个新兴市场？似乎他们对Linux的态度与几年前对互联网的兴起的反应
迟缓有些相似。但后来......唉，真希望Inprise不要步Netscape的后尘。C++Builder是
一个很有前途的开发工具。遗憾的是，Inprise公司Delphi的创始人已经跳槽到微软去主
持Visual J++项目了。但愿对Inprise冲击不会太大。微软的Visual C++的前景又怎样呢
？Visual Studio 7.0不久就要推出了。不知能不能在保持稳定性的同时在技术的先进性
上赶上C++Builder。另外，这一版本将加强网络开发的特性。看来微软虽然被判解体，
开发实力可是一点没打折扣。
就技术(主要指应用框架)来说，C++Builder目前领先于Visual C++。但多多少少
的不尽人意之处让我对Inprise“想说爱你不容易”。而VC尽管发展到今日已十分完善，
但MFC框架已是明日黄花了。如果不使用MFC，目前又没有合适的替代品。WFC是支持组件
、属性和事件的，但那是Visual J++里边用的；ATL也很先进，但是用来进行COM/Activ
eX开发的；基于ATL的WTL也不错，可惜是非官方作品，也未必比VCL先进。微软最近提出
了C#(读作C Sharp)语言方案，但那属于和Java同一类的东西。看来是金无足赤啊。根据
你的需要做选择吧。实际上Visual C++和C++Builder也不是单单竞争关系。它们在许多
领域并不重叠，甚至是互补的。到底怎样取舍，要根据你的项目特性决定。如果你开发
系统底层的东西，需要极好的兼容性和稳定性，选Visual C++吧。你可以只调用Window
s的各种API，不用MFC。如果你写传统的Windows桌面应用程序，Visual C++的MFC框架是
“正统”的选择。如果你为企业开发数据库、信息管理系统等高层应用(“高层”是相对
于“低层/底层”而言的，不是说技术高级或低级。)而且有比较紧的期限限制，选C++B
uilder比较好。如果你用的语言是Object Pascal，Delphi是唯一的选择(如果GNU Pasc
al等免费编译器不考虑的话)。如果你原先用Delphi(Object Pascal语言)，现在想改学
C++，应当先用C++Builder。熟悉的界面和相同的框架会让你的转轨事半功倍。
另外，虽说MFC已显落后，但不是说它不值得学。事实上，不学MFC就等于没学VC
。利用MFC框架开发程序仍然是目前开发桌面应用的主流模式，而且还会保持相当长的时
间。即使你不使用MFC框架，花点时间学习一下MFC的封装机制对你熟悉C++的OOP机制和
Windows底层功能也是很有好处的。
以上意见仅供参考。
如果有什么看法，请大家在在线讨论中进行讨论。
恶魔吹着笛子来 来自 苍天已死,黄天当立--c/c++的时代正在淡去 ：
不要以为这个题目是耸人听闻,但就目前的形势来看c/c++是需要退出舞台或者说的婉
转一点是需要更新换代了.
我想在未来的一两年里,作为程序员等级评判的标准之一c/c++(不管是mfc还是bcb)将
会让位给三种编程语言,1.sun的java2.windows平台上的c#3.xml
为什么这么说呢,我认为最大理由是目前的应用程序正在从基于独立的操作系统,传向
基于internet平台.
我们以前开发应用程序都是依赖于平台的功能调用,mfc,bcb都是这样.而现在日益火热
的internet编程却最不想关心的就是某一个平台的调用,譬如说要实现b2b的电子商务那
么就需要做不同平台的集成,如果我是程序员我最care的就是如何实现商务逻辑
而不是各种平台之间的通信和管理.那么我们最迫切需要的就是一种与各种平台调用无
关的语言,这中语言只注重程序逻辑的设计而不涉及平台的调用.而我们熟悉的c/c++却恰
恰不是为这个而设计的(赫赫这也不能怪c/c++在70年代谁能知道现在internet的情况呢
).c/c++的最初设计目的是为了设计unix产生一种介于汇编和高级语言之间的一种开发高
效而性能不低的语言.他要比其他任何高级语言都要关心系统的物理结构,譬如一直是毁
誉搀半的指针.指针之所以强大就是应为涉及了系统物理内存的管理.他可以使得程序员
和系统之间成为一种半透明状态.但是就是这种半透明的状态让指针带来了更多的不稳定
性.
c/c++在面向Internet的编程中却无任何优势可言.跨平台的电子商务软件最害怕顾及
各种平台之间的天差地别的系统调用,最害怕时不时的由于内存泄漏而crash.c/c++的优
势在这里却成为了劣势.即使在windows平台上开发基于windows dna的solution
用的最多的还是vb做的dcom而不是vc的atl做的dcom,因为c/c++虽然高效但是太容易
出错,如果不是很小心的释放内存nt很快就会资源不足.
java就是最先看到这种情况,他用jvm实现了平台无关用内存回收实现了稳定健壮.但是
相当多的c/c++程序员抱怨java太慢了.的确即使到java2速度仍然是一个大问题.我曾经
是一个c/c++坚决拥护者在许多论坛里和java程序员打笔仗.但是我逐渐意识到面对与in
ternet平台而不是特定的操作系统的时候java的速度问题往往是一个小小的瑕疵.我们可
以想象那一个电子商务网站会用我们手头的pc做服务器,他们不是sun的e1000就是ibm的
risc6000.在这种平台上java这点速度问题只是a peice of cake.程序员只需要专注与商
务逻辑的编程,而不必要关心数组是否越界,对象内存是否释放更不需要关心是不是unix
和windows的系统调用不一样.
微软的c#可以说是一种java与c/c++的杂合体,他可以回收内存,可以平台无关.但是
他又可以实现一些java没有的功能譬如在标记的程序段内用指针自己管理内存,可以实
现操作符的重载等等.为什么要这样做我想也许c#还肩负了一定的面向操作系统开发的任
务例如winform.他基本上的思想和java类似,但是实现的方法又不一样他不通过jvm解释
中间代码,而是吧源代码编译成p代码然后通过CLS库和JIT在平台上及时编译为100%的本
地代码来执行.他的pe代码是独立于平台的,但是cls和jit却根据不同的平台而设计.因此
c#的平台独立有点类似于c/c++在不同平台上的移植使得c#比java来的更快.而且微软还
许诺cls和jit不仅针对c#还可以针对任何语言譬如pascal,smaltalk,basic因此将来有可
能所有的编程语言都是可以平台无关的(ms真是毒,所有的语言都平台无关java还有什么
优势呢,据说ms正在开发基于pascal smaltalk的asp+).
xml很多人可能认为与html相类似的语言和c/c++,java,c#完全不在一个档次上的语言
.其实不然.我们知道不管是c#还是java都是通过统一地层计算来实现平台无关.那就必须
在性能上付出一点代价.而xml却能够实现不同的语言之间的调用.譬如说一个网占用jav
a用bean实现一个出货功能,另一个网站用dcom实现一个入库功能 .如果这个网站需要实
现b2b,用一般的方式就是在他们之间写转换程序.而xml通过标记语言来描述各自的借口
特性.两端通过解析xml文本来实现互相的调用,无需任何中间转换程序
只要一张xml文本就能实现bean和dcom之间的通讯(要说清楚其中的机理,需要很多xml
概念如果有兴趣可以到msdn.microsoft.com/xml或者www.s3c.org去看看).目前ms的.ne
t中最核心的技术soap就是完全基于xml的远过程调用.
介绍了那么多可能有点跑题,其实我最想说的就是21世纪的程序员应该从面向操作系统
的传统方法中走出来,学习一点如何面向Internet平台编程的技术和概念.不要在无畏的
那种c/c++工具好之类的地方争论.我想不出一两年不管是bcb还是mfc都要淘汰,
到那个时候要争论的不是bcb好还是mfc好而是c#好还是java好.至于xml那是不管sun和
ms以至于世界任何大的IT公司包括Intel,hp都在奋力研究的技术,不学习可能就要被淘汰
.至于c/c++可能就会沦落到现在汇编的地位在某些系统效能敏感的地方还能见得到.
如果是编程语言的初学者那么我建议学习java同时关注c#,他们首先比c/c++简单没有
复杂的宏,指针,摸版等等让人摸不招头脑的概念.而且是完全面向对象,比c/c++的半调子
面向对象清楚的多好学的多.(我推荐目前学习java,毕竟c#还没有发布而且刚发布的bet
a版的编译器要求高的吓人需要win2000 adv server没有128M内存的别想跑.话说回来c#
和java一摸一样没有什么太大的区别学好了java将来的c#将会信手拈来)
对于目前的windows下的编程者来说学习mfc的价值还是有一点的但是不是太大.至少可
以熟悉windows内在机理.但是我还是推荐关注一下c#将来的windows.net都是基于c#而不
是mfc.而且c#要比mfc简单的多实现一个同样的windows桌面应用c#的开发速度是mfc的两
到三倍而且几乎看不见性能的损失. visual studio 7.0中 vc将是一个次要的开发工具
最主要的开发工具就是c#和vb7.0.至于borland我想是不可能不跟着ms走至少windows平
台上是这样说不定明年就有一个c# builder出来作为borland的主打产品而不是c++buil
der了.说一句玩笑话wenny说不定很快会把这里变成www.c#help.net了
zhangxiuyong 来自 http://www.ucancode.com ：
其实我认为，对于Visual C++本身的理解不是向你上面谈到的那么简单，Microsoft
在开发Visual C++的时候是希望为其开发人员提供一个可靠的开发平台，便于用户可以
为Windows上面编写各个方面应用程序，包括：数据库应用程序，硬件驱动程序，网络程
序，多媒体程序，游戏程序等等方方面面，试想如果一个开发平台要同时完成这么多个
方面的开发任务，是需要考虑多少的问题，因此Visual C++在设计的时候就考虑了提供
一套类库而不是直接提供黑匣子式的开发组件来完成开发任务，提供的类库MFC具有很灵
活的设计结构，以及良好的继承性，同时配合DVS文挡视图结构来组织程序开发，虽然我
们承认利用VC开发程序（数据库方面的程序）没有其他的RAD开发工具来的快，但是如果
你真正利用VC来开发的话，你会觉得你不会去选用其他的开发工具的，对了各位听说个
多少开发人员是从VC熟练的开发师转向VB,Dephi的开发工具的吗，当然DVS结构本身也有
其很大的弱点，如很难重用。同时在CView中再嵌套CView的变得不可能。不过对于开发
中小型的程序（代码在50万行以内的程序却是可以的了）。对于特大型的程序我想最好
可以借鉴一种新的技术叫做MVC的开发技术来组织你的程序吧。好了各位此些文字，仅代
表个人之言，如果各位感兴趣可以到:http://www.ucancode.com上面看看。
zhangxiuyong 来自 http://www.ucancode.com ：
其实我认为，对于Visual C++本身的理解不是向你上面谈到的那么简单，Microsoft
在开发Visual C++的时候是希望为其开发人员提供一个可靠的开发平台，便于用户可以
为Windows上面编写各个方面应用程序，包括：数据库应用程序，硬件驱动程序，网络程
序，多媒体程序，游戏程序等等方方面面，试想如果一个开发平台要同时完成这么多个
方面的开发任务，是需要考虑多少的问题，因此Visual C++在设计的时候就考虑了提供
一套类库而不是直接提供黑匣子式的开发组件来完成开发任务，提供的类库MFC具有很灵
活的设计结构，以及良好的继承性，同时配合DVS文挡视图结构来组织程序开发，虽然我
们承认利用VC开发程序（数据库方面的程序）没有其他的RAD开发工具来的快，但是如果
你真正利用VC来开发的话，你会觉得你不会去选用其他的开发工具的，对了各位听说个
多少开发人员是从VC熟练的开发师转向VB,Dephi的开发工具的吗，当然DVS结构本身也有
其很大的弱点，如很难重用。同时在CView中再嵌套CView的变得不可能。不过对于开发
中小型的程序（代码在50万行以内的程序却是可以的了）。对于特大型的程序我想最好
可以借鉴一种新的技术叫做MVC的开发技术来组织你的程序吧。好了各位此些文字，仅代
表个人之言，如果各位感兴趣可以到:http://www.ucancode.com上面看看。
zhangxiuyong 来自 http://www.ucancode.com ：
其实我认为，对于Visual C++本身的理解不是向你上面谈到的那么简单，Microsoft
在开发Visual C++的时候是希望为其开发人员提供一个可靠的开发平台，便于用户可以
为Windows上面编写各个方面应用程序，包括：数据库应用程序，硬件驱动程序，网络程
序，多媒体程序，游戏程序等等方方面面，试想如果一个开发平台要同时完成这么多个
方面的开发任务，是需要考虑多少的问题，因此Visual C++在设计的时候就考虑了提供
一套类库而不是直接提供黑匣子式的开发组件来完成开发任务，提供的类库MFC具有很灵
活的设计结构，以及良好的继承性，同时配合DVS文挡视图结构来组织程序开发，虽然我
们承认利用VC开发程序（数据库方面的程序）没有其他的RAD开发工具来的快，但是如果
你真正利用VC来开发的话，你会觉得你不会去选用其他的开发工具的，对了各位听说个
多少开发人员是从VC熟练的开发师转向VB,Dephi的开发工具的吗，当然DVS结构本身也有
其很大的弱点，如很难重用。同时在CView中再嵌套CView的变得不可能。不过对于开发
中小型的程序（代码在50万行以内的程序却是可以的了）。对于特大型的程序我想最好
可以借鉴一种新的技术叫做MVC的开发技术来组织你的程序吧。好了各位此些文字，仅代
表个人之言，如果各位感兴趣可以到:http://www.ucancode.com上面看看。
wenyy 来自 http://www.vchelp.net ：
我一定程度上同意 恶魔吹着笛子来 的说法，
毕竟VC开发速度是比较慢的，
而且硬件速度的大规模提升也为使用JAVA开辟了道路，
不过microsoft.net的目的是一定程度上改变MS的经营性质，和开发关系不是很大，但
是MS的一贯方针都是在平台上为开发人员提供方便，
所以C#是为了.net服务的。
此外我想我没有精力再搞个c#help.net了。:-P
果子 来自 http:// ：
"恶魔吹着笛子来"是比较“前卫”的一类程序员。我就听业界的人多次说过JAVA也是
个吹得很响的东西，但实际如何，大家都看得见。至于认为C/C++开发工具（VC，
BCB等）会在一两年内退出市场，就是无稽之谈了。
Wesley 来自 http:// ：
恶魔吹着笛子来，你的观点很有启发性。能不能写一篇或推荐一篇剖析、比较Java开
发工具的文章？比如Visual J++, JBuilder，以及Symantec和IBM的对应工具。(可能和
本站的初衷有些不合^o^)
LeoCN 来自 http:// ：
It's not a time for us to determine which language will more better!
in factly,In China,too many corporation just writting some codes for
enterprise's MIS,OA,ERP or other application.It do not need so speed
and do not need so good original code. just want more data,more easy and m
ore quickly.
so c++ is not a choice in such enviroment. and u know,many codes we write
today will be useless.and there r so many easy tools such as VB
for windows designer, Developer/2000 or PB for database,Domino Designer fo
r OA application,why c++???
in DOS mode. i like Turbo c2.0, with it and MASM i can do everything.
but now i hate c++, it has waste my time! my corporation do not need
c++,just need java,xml,php,pb,vb,delphi,developer/2000,domino designer etc
.
so, a tool is just a tool,if the advantages in some aspect of the tool
u needed. it's will be a good tool for u. others it can bring u unfortunat
ly!
恶魔吹着笛子来 来自 ：
果子,国内的Java应用不到10%基本上是ms的天下.这些可能是由于中国软件业规模太小
的缘故.而在国外40%的商务系统的开发都是Java,c/c++不到10%.譬如BEA公司一个有3个
java程序员创立的公司开发了第一个基于J2EE的Application Server---weblogic.BEA公
司依靠weblogic在短短4年里成为世界第四大软件公司仅次于CA公司.可见JAVA的功能是
如何的强大.微软的.NET的负责人说,你们想要知道.NET是什么样子,那就去看看JAVA.JA
VA是什么样子.NET就是什么样子.
恶魔吹着笛子来 来自 http:// ：
Wesley你好.关于Java开发工具的问题.从我的观点来看,目前的Java开发工具没有一个
令人满意的.最主要的是,在技术上考虑的太多,却不像MS的开发工具考虑到程序员的方便
(vj++是另外一会事情我后面会讲).
基本上流行的是sun的jdk,ibm的visual age for jave,samtic 的visual cafe,和bor
land的jbuilder(vj++基本上没有什么人用).
在这几个工具来讲,jdk是老大哥,但是仅仅是一个command line compile.在某些方面
用ultreditor+jdk会比较方便,譬如你的机器的配置比较的低(memory<64M).一般来说,几
乎所有的Java工具需要的机器配置都比较高.
visual cafe是第一个可以使用的Java IDE工具,我当初学习Java的时候就是用这个.它
的配置要求比较低.一些比较低的版本譬如1.5 2.032M就可以使用了.但是现在最新的版
本5.0的要求就比较高了,可惜2.0以后的版本没有用过.cafe的IDE开发也不是很方便,懂
一个窗口西一个窗口比较的乱.而且bug还很多.有的时候trace到一定的地方
就会crash.samtic是一个系统安全公司不知道为什么cafe却那么不稳定.而且从技术上
来说到目前为止还没有完全支持java2.更不要说j2ee了.从帮助来说cafe的帮助基本上还
是jdk的帮助没有什么特别的地方.
IBM的东西往往是吹的比做的好.visual age很复杂功能也很多.支持100%pure Java和
J2EE.但是使用起来不方便,当初为了设一个class path找了半天的help都没有结果.后来
听别人说要在nt下面设置环境变量才能成功.而且与其说是visual age还不如说是comma
nd line套了一个windows壳子.做application还要自己写layout代码更本就不visual.
Jbuilder是我目前遇到最好的一个,它的界面基本上和delphi c++duilder差不多.他是
第一个真正的java的rad系统,第一个全面支持j2ee 13项Java技术的工具(bean,jsp,rmi
都实现了).100%的pure Java.相当全面的help document.
但是他最大的缺点是系统要求实在高,没有128M别想用.64M下面慢的像乌龟,help更本
不能开(它的help都是java写的64m下面打开help慢的能够看到一格一格awt画窗口的过程
).但是不管怎么说他是一个比较理想的系统.
至于visual j++.MS更本不是想用他来打开java市场,而是想用他来分裂java.从很大程
度上来说vj是一个windows 程序的java开发工具他不是100%的pure java.在windows平台
上他是最visual的.用他开发application,你不必用复杂的layout,只要像vb一样填写坐
标,而且开发的windows程序速度很快完全100%的本地代码.你可以把它看成java版的vb.
他的wfc库仅仅在windows上能够用,而且使java和com捆在一起.他自己开发jvm,java库.
但是ms污染java的策略相当的成功,不仅把java逼的走投无路还在法庭上赢了sun的java
官司.因此ms的目的一达倒就把vj便卖给另一个公司而且随着c#得开发和得不到sun的j2
ee的许可我想ms不会再开发任何关于java的工具.如果你开发java的同时还想使用ms下的
com,ado那么vj可以适合你的需要.
chenxiqi 来自 http://[email protected] ：
VC++开发数据库软件确实比较慢，可有许多软件只能用C/C++来开发，如果VC++退出历
史舞台，那岂不是说只有数据库软件才叫软件,我想世界不会如此单一。
zhangxiuyong 能告诉我什么是MVC的开发技术吗
恶魔吹着笛子来 来自 ：
什么样的的软件只能用c/c++开发?
操作系统?apple的OS7,os8,os9都是PASCAL开发的.
数据库?oracle8i就是JAVA开发的
游戏?你也许没有见过用DELPHI开发的<笑傲江湖><风云>,甚至有VB开发的<神龙教>
同时VB7.0全面支持direx8.0.可想而知游戏的难度会大大的降低吧.
MVC=Model, View, Controller Design Pattern
恶魔吹着笛子来 来自 ：
什么样的的软件只能用c/c++开发?
操作系统?apple的OS7,os8,os9都是PASCAL开发的.
数据库?oracle8i就是JAVA开发的
游戏?你也许没有见过用DELPHI开发的<笑傲江湖><风云>,甚至有VB开发的<神龙教>
同时VB7.0全面支持direx8.0.可想而知游戏的开发难度会大大的降低吧.
我的意思不是说c/c++会消失而是应用的范围将会大大的降低并且将会进行脱胎换骨的
升级(用了20几年升升级总可以吧,java的升级不算太成功,但是是一个不错的先例我想c
#的前景会更好).
BTW:
MVC=Model, View, Controller Design Pattern
xubin 来自 http:// ：
在工业控制中，直接对I/O地址操作，就要用C++。
恶魔吹着笛子来 来自 ：
俺有一个同学毕业设计用VB做单片机。你这不是在讨论问题是在抬杠。
wenyy 来自 http://www.vchelp.net ：
我想一种语言并不会因为其他语言的出现而消失，
比如说c与C++，C++与C#的关系。
所以我想讨论问题时首先是要排除敌视，
然后才是透彻的分析。
IT世界不光只有网络，还有其他很多。
所以某些工具在一定范围内适用是正常的，
其实在国外，
SERVER端软件大都用JAVA，而CLIENT却没有多少用JAVA，
这和速度有关，当然也与MS对JAVA的态度有关。
不过我一直认为C/C++不会因为JAVA的出现而消失。
就象COBOL目前为止还在使用一样，
不过以后会有愈来愈多的解释性语言出现，因为解释语言比编译语言的兼容性好，这
是不得不承认的。
恶魔吹着笛子来 来自 http:// ：
是的wenny.也许我说c/c++的消失有点夸张化了,但是实事求是的说.java和c#的出现
c/c++的升级换代是在所难免的.对么.
恶魔吹着笛子来 来自 http:// ：
而且我一直认为java和c#不是另外一种语言而是c++的升级.就象是c到c++的升级一样
.对不对.
xcc 来自 http:// ：
同意恶魔吹着笛子，你简直是我的偶像,顺便贴一篇关于C#和.NET专访
NET and C# Questions with Jeffrey Richter
In the weeks after Microsoft made a huge splash in the development communi
ty with their .NET and C# announcments at the July 2000 PDC, Jeffrey Richter
accepted our request to field 20 questions from our readers about these new
technologies. As many of you already know, Jeffrey is a cofounder of Wintel
lect, a company that specializes in Windows & Microsoft.Net training and deb
ugging. Jeff is also a consultant at Microsoft working on the Microsoft.NET
Common Runtime Language (CLR) team in which C# and Visual Basic 7 applicatio
ns operate. Below are the 20 most popular questions that were sent in and Je
ffrey's responses.
For Visual C++ developers everywhere still trying to get a handle on all t
his: Thanks Jeff!!
Question #1 Is .NET a runtime service or a development platform?
Answer It's both and actually a lot more. Microsoft .NET is a company-wide
initiative. It includes a new way of delivering software and services to bu
sinesses and consumers. A part of Microsoft.NET is the .NET Frameworks. The
frameworks is the first part of the MS.NET initiate to ship and it was given
out to attendees at the PDC in July. The .NET frameworks consists of two pa
rts: the .NET common language runtime and the .NET class library. These two
components are packaged together into the .NET Frameworks SDK which will be
available for free download from Microsoft's MSDN web site later this month.
In addition, the SDK also includes command-line compilers for C#, C++, JScr
ipt, and VB. You use these compilers to build applications and components. T
hese components require the runtime to execute so this is a development plat
form. When Visual Studio.NET ships, it will include the .NET SDK and a GUI e
ditor, wizards, tools, and a slew of other things. However, Visual Studio.NE
T is NOT required to build .NET applications.
Question #2 How likely it is for C# to become a general-purpose (meaning:
not MS-specific) language and if so, have any other vendors committed to pro
viding compilers on any non-Windows platforms?
Answer It's hard to answer this right now. I have been programming in C# a
lmost exclusively for about the past year and I love it. It only took me a f
ew days to learn most of it since it is very similar to C++. It was designed
to compliment the common language runtime and I think that it's unlikely to
gain much momentum if decoupled from the runtime. However, you never know.
Microsoft is submitting C# to the ECMA standards body so any company will ea
sily be able to produce their own C# compiler however, without a runtime, th
e compiler itself is not that useful. I'm not aware of any companies current
ly working on their own C# compiler. Certainly, porting the runtime to anoth
er OS is no small undertaking.
Question #3 Can you tell us specific practical problems that C# can fix be
tter than Java?
Answer I must be honest with you: I have never programmed in Java. I know
what C# offers the C/C++ programmer: simpler syntax, components that seamles
sly fit together, type safety, and so on. Other people should be able to add
ress the C# <-> Java comparison.
Question #4 Will ADO+ be the preferred and most efficient method to access
databases from C# or will it have it own (or .NET) class wrappers for the O
LEDB API?
Answer The .NET class library includes a System.Data namespace with many t
ypes for database access. These wrappers will be the best (and most efficien
t) way for a C# programmer to access data.
Question #5 Can C# be used to develop Windows applications or is it soley
used for developing distributed applications?
Answer C# can absolutely be used to develop classic-style Windows applicat
ions. Actually, this is more a function of the runtime, not the language. So
, the runtime supports console apps, GUI applications, NT Service applicatio
ns, simple components which can be used in applications, web pages and so on
. You can't write a device driver but that's about all I can think of that t
he runtime doesn't support.
Question #6 What is the C# relationship to WinForms?
Answer Win Forms is a set of classes in the .NET class library that wrap W
in32 windows, brushes, pens, etc. Any language targeting the runtime (includ
ing C#) can construct instances of these types and manipulate them. This is
how you would create an app like Notepad, Calc, or Wordpad. I know that Win
Forms has similarity to J++'s WFC library but I also know that there have be
en some major changes.
Question #7 Rumor has it that the C# language has been submitted to the EC
MA for ratification. Is this true and what impact do you see that having on
other companies adopting it as a general language (such as C and C++)?
Answer Yes, it is true. I pretty much answered this in question 2.
Question #8 Which will be the role of ATL and COM in the new .NET technolo
gies?
Answer The .NET frameworks offers a replacement for many existing librarie
s, like ATL, MFC, C runtime library, standard template library and so on. .N
ET programming is significantly easier than using any of these older technol
ogies. For this reason, I suspect many developers will move away from using
the older technologies. The older technologies can buy you performance howev
er; so, some people that are very concerned about this will stick with what'
s around. As for COM, developing components with .NET is orders of magnitude
easier and the interoperation between components pretty much happens for fr
ee. Again performance may be an issue for some. And, for the time being COM+
services, like transactions, are not being offered directly to .NET code. Y
ou can still access these COM+ services but .NET code must incur an interope
rability transition, which translates to a performance hit.
Question #9 Why was the templates feature not carried over from C++ to C#?
Answer Again, this is more of a runtime issue than a C# issue. First, temp
lates are difficult to implement and Microsoft choose not to do the work for
Version 1 of the product. They may do templates or something similar in fut
ure versions. Second, since the runtime is a multi-language runtime, introdu
cing templates means that all languages targeting the runtime would be requi
red to support templates in some form. There are a lot of issues here that n
eed to be carefully considered.
Question #10 Will C# replace the pseudo keywords that clutter ATL COM code
with real keywords? Examples: OLE_COLOR, BOOL, VARIANT_BOOL, and DISPID_XXX
XXX.
Answer Absolutely, all types have new names as provided by the .NET class
library.
Question #11 We've seen managed extensions, but aside from that, what futu
re does C++ have at MS and in .NET?
Answer C++ is unique in that it is the only Microsoft language that allows
the developer to write managed and unmanaged code. So, I can easily see dev
elopers writing in unmanaged C++ for performance-critical algorithms and the
n using managed C++ for type-safety and component interoperability. I'm sure
Microsoft will keep C++ going for years to come: device drivers need it, Wi
ndows is built with it, SQL Server< Exchange, and other BackOffice products
will probably use C++ for a long, long time.
Question #12 If .NET supports ActiveX/COM, how will security be assured if
a C# application runs from within a browser?
Answer The .NET runtime offers code access security, which allows an admin
istrator/user to configure security based on code identify. By default, any
code downloaded via the Internet or intranet is untrusted and will not be ab
le to access files and other resources. In fact, when I build a console appl
ication and run it from a network share, I get an exception when it tries to
access certain resources. If I copy the same file to a local disk directory
and run it, it runs fine. Code access security is integrated with the runti
me and is too deep a subject to cover here.
Question #13 With regards to the .NET runtime, do I need it on the machine
that I deploy C# apps on?
Answer Yes. All managed apps need a manager; the runtime is the manager. M
icrosoft will eventually package the runtime so that it is freely redistribu
ted. For now, end-users will have to install the full .NET SDK from MSDN web
site (when available). This is similar to how VB developer must ship the VB
runtime today.
Question #14 There has been mention of being able to derive C# classes fro
m VB classes. Is this true and where can we see an example of how to do this
?
Answer This is true. In fact, any language that targets the runtime can de
rive from any type created in another language. Also, the Visual Studio debu
gger fully supports debugging across languages. Each entry in the call stack
window shows the function on the stack and the language that the function w
as written in. This is very cool and got a round of spontaneous applause whe
n shown at the PDC. There are samples in the .NET SDK that demonstrate how t
o do this. It's really quite simple. Actually it just happens, there is noth
ing for you to do. You can also throw exception across language boundaries a
s well for error handling.
Question #15 Can I derive a C# class from a C++ class? If so, how?
Answer Same as the answer above: Any managed language can inherit from a t
ype in another other managed language. If you use native C++, then you can't
do this, however.
Question #16 Will the new version of MFC have the option of working in a m
anaged environment?
Answer I haven't been tracking the new version of MFC but I'm pretty sure
the answer is no. MFC is all unmanaged just like it has always been. For man
aged applications, Win Forms is the window manager that people should use.
Question #17 If the new version of MFC will operate in a managed environme
nt, will it have the option of building desktop Win32 apps and not needing .
NET runtime support?
Answer I'm pretty sure MFC is unmanaged and will never require the runtime
.
Question #18 Stroustrup has been quoted as saying "I have not expressed a
technical opinion on C#, and I don't plan to do so. C# is yet another propri
etary language specialized for Microsoft's Windows system." Do you agree or
do you think C# is more of a generic language open to other platforms?
Answer C# is a language designed for the common language runtime; not Wind
ows. The CLR can be ported to other operating system like Linux and Solaris
and if the CLR is there, then C# will probably be there as well. In the gran
d scheme of things, C# is not that important or interesting. It is a syntax
checker that spits out intermediate language consumable by the runtime. You
can love C# or hate C# - your choice. I happen to love it and think is the b
est programming language for the types of applications I write.
Question #19 I heard a rumor that VB7 will allow static linking of the run
time, like MFC. Is there any truth in this? If so, will C# also be able to c
reate standalone apps?
Answer This is absolutely not true. No language will able to statically li
nk to the runtime.
Question #20 Does C# still use resource files? If not, what mechanism is p
rovided to allow for localization?
Answer The .NET frameworks designers have created a new resource model. Re
sources can be embedded in EXE or DLL files the way Win32 resources are or r
esources files can now be stand-alone files like a single jpg or bmp file. T
here is also the concept of fall-back cultures. If the Swiss German resource
can't be found, the runtime looks for the German resource. If the German re
source can't be fond, it looks for the "default" resource. Each language wil
l typically be built and shipped as a separate assembly rather than packagin
g everything up into a single file. Like code access security, a full discus
sion of the new resource model is too much to put here.
wenyy 来自 http://www.vchelp.net ：
我想应该这样说，一种新语言的出现会在一定的功能领域上替代其他的开发语言，以
前的开发语言的使用范围会缩小，但不会消失。（就算是出于保护现有资源的目的）
但没有一中语言是十全十美的，
JAVA，C#都不是。
wenyy 来自 http://www.vchelp.net ：
》》恶魔吹着笛子来
你好，
很高兴能够与你进行讨论，
虽然本站名字叫做vchelp.net
但我不排斥其他的开发语言，只是自己的能力有限不能将本站内容扩展到其他的语言
，
但我很希望大家在本站对开发中可能遇到的问题和矛盾进行讨论，不论是关于语言还
是开发方法的。
我想邀请你成为本站个人专栏的作者，
你可以发表一些你关于开发的想法，就算是与VC无关也没关系。当然在时间上也没有
要求，你有时间就写写。
盼复：[email protected]
cuixue 来自 http:// ：
看了各位大侠的话，觉得好像在讨论java,其实历来有两派，smth几乎天天在吵，
喜欢java的同志到各个地方布道，连perl也不放过。呵呵。我个人觉得java先天有一
些劣势使得他无法取代c/c++的，他的垃圾收集只不过通过一个线程来完成，这对实时系
统是来不及的，EJB的推出也说明java原来是不适合企业级开发的，没有语言是天生完美
的。java最大的困难我觉得来自microsoft的刁难，c#的推出无疑会夺走windows平台上
的java份额。java的速度也就不说了。jbuidler的速度不能够忍受阿，可是这样一个产
品就是java写的。由于个人见识不够，实在不能理解海量吞吐的
server用java.oracle用java是实现了ejb的集成把，他的数据库engine是不是java 的
那？请大侠指点。而且当时号称8i不要操作系统，结果市场反应平平，还好
搭上了e-commerce这班车，：）
在说说我对vc和bcb的看法，这两样我都算粗粗用过，紫云影说得挺好的，比较公正。
MFC的确稳定，ATL未免有点复杂，要不WTL就不会出来了。vcl的源码有一部分是pascal
写的，这点有点差，不过他的扩展性很好，用用就知道了，决不是好多人认为的vb式的
傻瓜工具。道理很简单，应为他是符合ansi标准的c/c++语言。其实vc是不够ansi的，C
String就是不符合的，所以bcb用了 AnsiString.可惜bcb不够稳定。
提示太慢。帮助的问题我是这样看得，msdn不是专门给vc的，他是windows开发的指南
，用bcb一样也很有用，是个宝贝。
好了，不说了，反正按需所取把。
cuixue 来自 http:// ：
xml远程调用无疑是平台无关调用的一大进步，可是这也不能说corba就要消失了，
xml这种标记语言虽然提供了强大的标志检索的能力，可是它本身的缺点是与以前系统
的兼容性，所以最近推出了xhtml以兼容以前的应用。电子商务的应用有不同的类型，
对于一般的b2c的应用，sun e1000上跑跑java或许可以，如果是银行的主机，起码
1000笔每秒，java是不是可以 那？硬件的提高不是没有限度的，而且现在数据中心和
OLAP的流行，对实时的要求更高了，实际上对于单位应用硬件资源并没有什么起色。而
且数据发掘的应用要求对原有资源的兼容，对于中间件而言java开发是有优势的，corb
a提供了对异构网络的良好支持，ejb也在向它靠，毕竟在这个年代，不可能只存在一个
系统，一种语言，对自身的改造和对异构网络的支持以及原有应用的支持是每种语言都
要面对的难题。
杨宁 来自 http:// ：
世界是多样性的世界。
不面向应用，一切都是废物。
学好编译原理和操作系统，以不变应万变。
人的精力有限，面面俱到等于面面难到！
妖刀 来自 http:// ：
我不会编一辈子程序,我需要简单,快速.我只要他好掌握,能实现功能.
至于是专家型的C++还是傻瓜型的VB(Delphi也差不多)我不在乎.
老板也不在乎
TOM 来自 http:// ：
用VC++和Delphi都各有千秋，Delphi写界面方便，大部分是写数据库程序。但写出来
的程序太大，如果做一个组件（为HTML写的）还是用VC好，有句话很好，专业的程序员
用VC,聪明的程序员用Delphi,
TOM 来自 http:// ：
用VC++和Delphi都各有千秋，Delphi写界面方便，大部分是写数据库程序。但写出来
的程序太大，如果做一个组件（为HTML写的）还是用VC好，有句话很好，专业的程序员
用VC,聪明的程序员用Delphi,
宇服 来自 http:// ：
作为一个真正的程序员，不懂c/c++ 只能与非专业人士一样，改改属性来作程序罢了
。
宇服 来自 http:// ：
恶魔吹着笛子来的话太可怕了，世界可能只有java存在了？？？？？
wenyy 来自 http://www.vchelp.net ：
我很同意杨宁的观点
》》》世界是多样性的世界。 不面向应用，一切都是废物。
苏 来自 http:// ：
对于DELPHI跟VC的争议已经不是一天两天的了,要理论它们的长短处确实比较困难.
作为比较出色的RAD开发工具我认为是DELPHI,VC是称不上RAD的!对于编程者而言,如果
是低层的东西用VC开发具有明朗的线条--一句一句来,而用DELPHI就必须借用API了(当然
用起来就不是很方便了);而对于从事数据库开发DELPHI不失为一个好工具!我觉得两者各
有长处吧!
雅各宾派 来自 http:// ：
呵呵，明朗的线条，此言得之。
Hintell 来自 http:// ：
我爱JAVA,如果不是为了谋生,我立马放弃现在的UNIX/C PROGRAMMING,不过幸好搞的算
是交易中间件
JAVA是个好东东!
恶魔吹着笛子来 来自 ：
我从来就没有说果,只有JAVA会存在.我只是说,将来的很多我们熟悉的桌面应用都要以
WEB服务形式出现(包括我们的现在常用的office,windows,visualstudio等等),而客户端
仅仅是一个外壳.你没有听说5年以后ms将不再买osftware,而是靠买网上的服务(office
.net,windows.net).这个时候我想传统的c/c++的应用范围就会小的多,而c/c++的升级版
本类似于java,c#就是主流因为他们是为internet设计的而c/c++不是.还有我认为,java
,c#和c/c++不是对立,要我把java,c#和c/c++对立起来,我宁愿
把java,c#看作是c/c++的一种internet延伸和升级,使得c/c++更加符合internet的需
要.我们用java,c#的时候我们很大程度上使用了c/c++大约60%的legcy功能,我们能不感
谢c/c++么.我一直强调的是java和c#是C/C++的衍生,我们在用JAVA时我并不感到是在另
外一个世界里写程序我感到的是我仍然在C语言的世界.我想我们不该
有JAVA,C#和c/c++语言的门户之间.有可能的话我希望称他们为c语言族(c/c++/java|
c#).
hfgh 来自 http://无 ：
不要再去争论什么DELPHI、VC了，语言只是工具。软件的关键是创新和设计，
有了这个前提，用什么工具去做就看你熟悉什么工具了，看你的工具能不能
满足你的设计目标，有限制就选择别的工具。就这么简单，有必要去争论用
什么工具吗？应该是争论一个软件的创意和设计有没有前途，而不是先去争
论用什么工具。每个工具都有它的优缺点，主要是看你是否熟悉它，它能不
能顺利实现你的目标。如果不能，没办法，选另外一个工具。做界面还是
DELPHI合适，做高效率的通信，还是VC，要做大量涉及SDK或底层的东西，还
是VC，就看你项目的目标是什么，而且是每个目标，不是其中某一个目标。
中国的程序员都受中国教育的限制，老是在一些细节和工具的层次上思考，
没有在全面的系统层次上思考，在整个计算机技术、通信技术、软件技术的
整体面上思考问题，才是中国软件技术进步的道路和方向，而不是去争论用
什么工具。另外，本人认为VCHELP网站在中国还是办得不错，但欠缺的是整体
技术层面上的东西，而这一点在中国是尤其重要和迫切需要。
回复
姓名
邮件地址
主页地址
你的回答
返回 Visual C++/MFC 开发指南在线讨论区
--------------------------------------------------------------------------
------
闻怡洋 1999年10月03日成家立页 http://www.vchelp.net(c)版权所有
--
本文地址：http://com.8s8s.com/it/it30208.htm