如果不是看在300分的面子上
我才不会在这儿争什么主义的.
还是那句话:
多解决一些问题,少谈什么主义(梁实秋语)
以下是转载于WWW.VCHELP.NET的讨论
长了点先说一声对不起
---------------------------------------------------------------------
查看问题及答案
序号 25 请对 Visual C++与Delphi/C++Builder之比较 一文发表看法
wenyy 来自 http://www.vchelp.net：
Visual C++与Delphi/C++Builder之比较
作者：紫云英
JasonCrazy@sina.com 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++Builder归入“同一阵线”。我在网上见到一些Delphi程序员认为C++Builder与VC比较接近，这是个误解。事实上，Delphi和C++Builder除了使用的语言不同，其余几乎都相同。为了避免话题转移到C++语言与Object Pascal语言(即Delphi所用的语言)的比较，下文主要对比分析Visual C++与C++Builder。
首先，从它们的应用程序框架(Application Frame，有时也称为对象框架)进行比较。Visual C++采用的框架是MFC。MFC不仅仅是人们通常理解的一个类库。(同样，Delphi和C++Builder使用的VCL的概念也不仅仅是一个控件库。)你如果选择了MFC，也就选择了一种程序结构，一种编程风格。MFC早在Windows 3.x的时代就出现了，那时的Visual C++还是16位的。经过这些年的不断补充和完善，MFC已经十分成熟。但由于原型出现得比较早，MFC相比于VCL落后了一个时代。尽管微软对MFC的更新没有停止，我也经常读到持“只要Windows不过时，MFC就不会过时”之类观点的文章，但就象Inprise(原Borland)的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++Builder的兼容性好，实际上很大程度应归功于MFC的兼容性好。微软辛辛苦苦用标准方法写MFC，却为对手制造了方便。不知他们作何感想？而因为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 Pascal代码，但C++Builder仍不能使用为Delphi开发的VCL组件。所以一个组件有for D1/D2/D3/D4/D5/C1/C3/C4/C5这些不同版本是常有的事，而且随着C++Builder版本的升级可能还会增加。希望Inprise能先解决同门兄弟的兼容性问题。而微软的VC就没有这类问题。MFC1.0的程序也可以毫无障碍地在VC6.0下编译通过。
再来看看它们的前景吧。实际上，技术的进步在很多时候是此消彼长的。当初Borland的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 Issues部分，以及它们的帮助文档的规模和质量都可以看出。(哪个同类产品的帮助文档能和MSDN比呢？)Inprise公司应从Netscape吸取教训，不要让C++Builder成为第二个Netscape Communicator。(Communicator也是一度技术领先，甚至曾占据了大部分的浏览器市场，但似乎后劲不足，而且 6.0 PR1、2中bug多多，现在被IE压得抬不起头。)C++Builder是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/ActiveX开发的；基于ATL的WTL也不错，可惜是非官方作品，也未必比VCL先进。微软最近提出了C#(读作C Sharp)语言方案，但那属于和Java同一类的东西。看来是金无足赤啊。根据你的需要做选择吧。实际上Visual C++和C++Builder也不是单单竞争关系。它们在许多领域并不重叠，甚至是互补的。到底怎样取舍，要根据你的项目特性决定。如果你开发系统底层的东西，需要极好的兼容性和稳定性，选Visual C++吧。你可以只调用Windows的各种API，不用MFC。如果你写传统的Windows桌面应用程序，Visual C++的MFC框架是“正统”的选择。如果你为企业开发数据库、信息管理系统等高层应用(“高层”是相对于“低层/底层”而言的，不是说技术高级或低级。)而且有比较紧的期限限制，选C++Builder比较好。如果你用的语言是Object Pascal，Delphi是唯一的选择(如果GNU Pascal等免费编译器不考虑的话)。如果你原先用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程序员打笔仗.但是我逐渐意识到面对与internet平台而不是特定的操作系统的时候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却能够实现不同的语言之间的调用.譬如说一个网占用java用bean实现一个出货功能,另一个网站用dcom实现一个入库功能 .如果这个网站需要实现b2b,用一般的方式就是在他们之间写转换程序.而xml通过标记语言来描述各自的借口特性.两端通过解析xml文本来实现互相的调用,无需任何中间转换程序
只要一张xml文本就能实现bean和dcom之间的通讯(要说清楚其中的机理,需要很多xml概念如果有兴趣可以到msdn.microsoft.com/xml或者www.s3c.org去看看).目前ms的.net中最核心的技术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#还没有发布而且刚发布的beta版的编译器要求高的吓人需要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++builder了.说一句玩笑话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了。
果子 来自 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 more 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 for 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 unfortunatly!
恶魔吹着笛子来 来自 ：
果子,国内的Java应用不到10%基本上是ms的天下.这些可能是由于中国软件业规模太小的缘故.而在国外40%的商务系统的开发都是Java,c/c++不到10%.譬如BEA公司一个有3个java程序员创立的公司开发了第一个基于J2EE的Application Server---weblogic.BEA公司依靠weblogic在短短4年里成为世界第四大软件公司仅次于CA公司.可见JAVA的功能是如何的强大.微软的.NET的负责人说,你们想要知道.NET是什么样子,那就去看看JAVA.JAVA是什么样子.NET就是什么样子.
恶魔吹着笛子来 来自 http:// ：
Wesley你好.关于Java开发工具的问题.从我的观点来看,目前的Java开发工具没有一个令人满意的.最主要的是,在技术上考虑的太多,却不像MS的开发工具考虑到程序员的方便(vj++是另外一会事情我后面会讲).
基本上流行的是sun的jdk,ibm的visual age for jave,samtic 的visual cafe,和borland的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还不如说是command 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的j2ee的许可我想ms不会再开发任何关于java的工具.如果你开发java的同时还想使用ms下的com,ado那么vj可以适合你的需要.
chenxiqi 来自 http://chenxiqi@yeah.net ：
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 community 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 Wintellect, a company that specializes in Windows & Microsoft.Net training and debugging. Jeff is also a consultant at Microsoft working on the Microsoft.NET Common Runtime Language (CLR) team in which C# and Visual Basic 7 applications operate. Below are the 20 most popular questions that were sent in and Jeffrey's responses.
For Visual C++ developers everywhere still trying to get a handle on all this: 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 businesses 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 parts: 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++, JScript, and VB. You use these compilers to build applications and components. These components require the runtime to execute so this is a development platform. When Visual Studio.NET ships, it will include the .NET SDK and a GUI editor, wizards, tools, and a slew of other things. However, Visual Studio.NET 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 providing compilers on any non-Windows platforms?
Answer It's hard to answer this right now. I have been programming in C# almost exclusively for about the past year and I love it. It only took me a few 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 easily be able to produce their own C# compiler however, without a runtime, the compiler itself is not that useful. I'm not aware of any companies currently working on their own C# compiler. Certainly, porting the runtime to another OS is no small undertaking.
Question #3 Can you tell us specific practical problems that C# can fix better 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 seamlessly fit together, type safety, and so on. Other people should be able to address 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 OLEDB API?
Answer The .NET class library includes a System.Data namespace with many types for database access. These wrappers will be the best (and most efficient) 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 applications. Actually, this is more a function of the runtime, not the language. So, the runtime supports console apps, GUI applications, NT Service applications, 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 the 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 Win32 windows, brushes, pens, etc. Any language targeting the runtime (including 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 been some major changes.
Question #7 Rumor has it that the C# language has been submitted to the ECMA 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 technologies?
Answer The .NET frameworks offers a replacement for many existing libraries, like ATL, MFC, C runtime library, standard template library and so on. .NET programming is significantly easier than using any of these older technologies. For this reason, I suspect many developers will move away from using the older technologies. The older technologies can buy you performance however; 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 free. 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. You can still access these COM+ services but .NET code must incur an interoperability 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, templates 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 future versions. Second, since the runtime is a multi-language runtime, introducing templates means that all languages targeting the runtime would be required to support templates in some form. There are a lot of issues here that need 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_XXXXXX.
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 future 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 developers writing in unmanaged C++ for performance-critical algorithms and then 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, Windows 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 administrator/user to configure security based on code identify. By default, any code downloaded via the Internet or intranet is untrusted and will not be able to access files and other resources. In fact, when I build a console application 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 runtime 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. Microsoft will eventually package the runtime so that it is freely redistributed. 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 from 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 derive from any type created in another language. Also, the Visual Studio debugger fully supports debugging across languages. Each entry in the call stack window shows the function on the stack and the language that the function was written in. This is very cool and got a round of spontaneous applause when shown at the PDC. There are samples in the .NET SDK that demonstrate how to do this. It's really quite simple. Actually it just happens, there is nothing for you to do. You can also throw exception across language boundaries as 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 type 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 managed 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 managed applications, Win Forms is the window manager that people should use.
Question #17 If the new version of MFC will operate in a managed environment, 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 proprietary 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 Windows. 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 grand 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 best programming language for the types of applications I write.
Question #19 I heard a rumor that VB7 will allow static linking of the runtime, like MFC. Is there any truth in this? If so, will C# also be able to create standalone apps?
Answer This is absolutely not true. No language will able to statically link to the runtime.
Question #20 Does C# still use resource files? If not, what mechanism is provided to allow for localization?
Answer The .NET frameworks designers have created a new resource model. Resources can be embedded in EXE or DLL files the way Win32 resources are or resources files can now be stand-alone files like a single jpg or bmp file. There 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 resource can't be fond, it looks for the "default" resource. Each language will typically be built and shipped as a separate assembly rather than packaging everything up into a single file. Like code access security, a full discussion 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无关也没关系。当然在时间上也没有要求，你有时间就写写。
盼复：wyy_cq@21cn.com
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的，CString就是不符合的，所以bcb用了 AnsiString.可惜bcb不够稳定。
提示太慢。帮助的问题我是这样看得，msdn不是专门给vc的，他是windows开发的指南，用bcb一样也很有用，是个宝贝。
好了，不说了，反正按需所取把。
cuixue 来自 http:// ：
xml远程调用无疑是平台无关调用的一大进步，可是这也不能说corba就要消失了，
xml这种标记语言虽然提供了强大的标志检索的能力，可是它本身的缺点是与以前系统的兼容性，所以最近推出了xhtml以兼容以前的应用。电子商务的应用有不同的类型，
对于一般的b2c的应用，sun e1000上跑跑java或许可以，如果是银行的主机，起码
1000笔每秒，java是不是可以 那？硬件的提高不是没有限度的，而且现在数据中心和OLAP的流行，对实时的要求更高了，实际上对于单位应用硬件资源并没有什么起色。而且数据发掘的应用要求对原有资源的兼容，对于中间件而言java开发是有优势的，corba提供了对异构网络的良好支持，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网站在中国还是办得不错，但欠缺的是整体
技术层面上的东西，而这一点在中国是尤其重要和迫切需要。
维杨 卜算子 来自 http:// ：
用 vc 做 dll， 或 com
用 cb 做 界面
这是我的选择！
睡不醒的猫 来自 http:// ：
vc or delphi,看看市场上那些最赚钱的软件就行了，难到有人真的相信用几个星期写出个三脚猫，毫无自己特色的程序就能混碗饭吃了？数据库软件（除非库特大），就我看，是最简单，最能糊弄那些外行人的东西了，有没有想过，还有cad,系统仿真那些动辄就卖十几万的东西，用delphi，java简直是场噩梦，对一个有点事业心，有点荣誉感的人，还是耐下心学点真真的程序设计吧，不要人云亦云。
三岁孩娃 来自 http:// ：
我的选择方式很简单，也很外。
我就因为喜欢VC。JAVA的句式。 对DELPHI。VB。PASCAL。。。。一看就烦。
所以，我选学了VC，JAVA。其它不多想，另外，我想C#尽快出台。
三岁孩娃 来自 http:// ：
编程是一种工作，责任。但它也是一种艺术，对于作品的成熟与完美才是最重要的。
你可以选用很普通的画笔作画。也许=====你用脚丫子，踏上墨，###￥￥#432#一付绝美的作品。 意思是说，不论你用那种开发工具，只要你能精通，有很好的作品创意，把它做出来，卖出去，成就中国的微软才是最最重要的。请大家说现要那种开发工具最不好，#￥·#·%#·￥%￥可我就要用，我为什么不能用它作的更好呢，或把它做得更好呢。
呵呵，三岁傻帽一个，瞎说。
Microbao 来自 http://www.china-erp.com ：
如果你考虑的是界面的设计，涉及I/O，请使用VC。
如果你考虑的是开发速度，做ERP，MRP请使用VB,Delphi.
如果你是专门的数据库开发者，请使用PB，
如果你是专门的INTERNET开发者，请使用Java.
不用争了，不管是黑猫还是白猫，只要能抓到老鼠，就是好猫!!!
lxsuperman 来自 http:// ：
apple的OS7,os8,os9都是PASCAL开发的.但，这个pascal是标准的吗？
oracle8i就是JAVA开发的，但，java的解释程序是用什么开发的呢？也是java吗？
你也许没有见过用DELPHI开发的<笑傲江湖><风云>,甚至有VB开发的<神龙教>
同时VB7.0全面支持direx8.0.可想而知游戏的开发难度会大大的降低吧.
也都可以，但这些工具还有原来语言的样子吗？如果说VC++的MFC库很难懂，
那么VB的库你抛系的明白吗？（我看不见得比MFC简单多少）。
其实，我也不是非说，用于编程的工具就只能用C/C++，但是也不是象大家所说的
一无是处，马上淘汰吧！！！
当然，C/C++用了20年了也应该变变了，但关键是真的需要吗？
从C变到C++这很好，很对，因为需要，C以不能满足日益庞大的软件代码了。
当然，随着人们对编译原理的任知，编程思想的理解的提高与深入。明白不管那一种
语言工具pascal,basic,c,c++,java等，都可以互通的只不过换个符号而以（当然不是如此简单），但是从标准（不加修改）的语法上支持强大、广泛和使用的工具
还是C/C++。
可是，大家会说现代是网络时代互联才是主要，而C/C++的网络功能几乎等于没有，
而它支持的网络太低端没有用。对没错，VC++或BC++B是有这个弊病，
但是大家不要忘了，网络是靠什么够架起来的，是靠成千上万的“单机”（泛指）联成的，没有这些“单机”那有网络可谈，而这些“单机”也要靠强大的软件和协议
相互支持才能构成网络的。难道这些软件和协议也要靠C#,JAVA等来完成吗？
而且C/C++真的不如BASIC吗？用VB做的DCOM真的比VC++的ATL做的好？
我听说微软的DCOM是用C++做的，难道VB编译成的汇编指令会比VC编译成的汇编指令
同C++编译成的汇编指令兼容性好？
所以，我认为这些工具各有个的长处，各有个的缺点，是相互互补的。拿JAVA的长处比C/C++的短处，我觉得不公平，况且JAVA能的C/C++不见得不能，就拿JAVA的
跨平台说吧。其实java也是跨平台的，用的是把软件抽象成硬件使用，生成的是软件认知的指令代码，这样如果每个操作系统有java硬件虚拟机那么就实现了所谓的跨平台，c#也是如此。如果，全球所有计算机在硬件指令上相互兼容得到统一，java没有任何意义。但是，C/C++也可做成这样，只不过要自己做两部分，一部分编译，一部分发送，当然相当麻芬。
我其实是主张做什么事用什么工具，那一工具在你做的事上是长项就用那一工具。
所以，这些工具比来比去的讨论，其实是无聊至及。
还有 恶魔吹着笛子来 的思想是很超前，但现在C/C++的功能相对还是强大的，
C/C++目前扮演的就象20年前的汇编，而JAVA，VB，DELPHI就象当时的高级语言
针对很性，所以，C/C++目前不会退出市场，将来会逐渐退出，但却不会被JAVA
等取代，而是会有新的编程思想，如同从结构到对象一般，而且这个时间不会短的
Neithardt 来自 http:// ：
我不赞成单从技术层面来讨论语言的优劣，毕竟使用这些语言的最终目的就是要在各个领域里面作商业应用，而不是大学的研究人员那样单纯的做技术验证。如果使用一种语言做出来的系统，能够确实的减少客户的成本，那么这种语言对于客户来讲就是一种好的语言，语言是如此，IDE更是如此。
要推动商业公司使用某种产品，必须要使他们相信使用这些产品除了能够具有公司所需要的功能外，还能够有效的节省公司的成本。为什么要进行电脑化管理？为什么要自动化？目的就是一个------尽最大的努力压缩成本。
JAVA就具有这样的优势。因为它是一种忽略了OS以及地域限制的语言，要运行JAVA写的软件，只需要在不同平台上的解释器而已。至于很多人把不用指针也作为它的优点之一，我不敢同意。这只不过是为了让JAVA能够有多平台之上的兼容性而做的限制而已，如果JAVA允许用指针，它对不同平台的兼容优势就不复存在了。由此可见，JAVA在维护成本上具有不可比拟的优势，而维护成本在软件的总成本中占60%以上，JAVA的优势不言自明。
老说.net，其实说白了就是大家都不买软件了，一起去租软件用，也就是象用自来水一样使用软件。对于公司来说是很重要的，俗话说得好，买不如租，光更新一套软件就不少钱，（国内的公司除外，因为他们绝大部分都是用的盗版，软件成本对于他们来说基本等于零。）租比买划得来，成本省下不少，尤其对于大部分的中小公司来说，节省成本就是赢利。而C++在编.net软件时一点优势也没有，因为它要从底下开始干。但是JAVA可以直接考虑如何做了，光这一点来看，JAVA一定会成为主流。
软件在要进入.net时代，那么下一种最流行的语言应该是类JAVA语言，即有平台无关性及分布处理的能力，但问题是进入.net时代的时间有多长？总不能大家都停下来，等到进入了.net咱再写软件吧？所以现阶段唱主角的还是C++、Pascal等等的语言，JAVA是一种有潜力的语言，但不会是现在最流行的语言，在桌面时代，JAVA没有优势。其实C++和JAVA就象是刀和枪一样，枪比刀先进，尤其是在打仗的时候，但是不是说有了枪在打仗时就不用刀呢？
另一个问题就是关于JAVA和C++/C的关系问题。我赞同恶魔吹着笛子来的看法，即JAVA应该是属于C语言家族的。大家听过这句话没有？“C++应该是JAVA”，这句话是在JAVA的程序员中很流行的，意思是说如果JAVA早出二十年，那么就不会有C++了，虽然比较的片面，毕竟JAVA与C差别挺大的，但这说明了JAVA与C语言家族的关系。别的不说，单看一下JAVA的语法就知道了，懂C++的看懂JAVA的源代码不成问题。
~{:zK50K5@~} 来自 http:// ：
~{2;9/J2C4SoQT#,V;R*D/9;4o5=PhR*#,>MR;GP~}OK
~{UfU}5D3LPrT1#,VXJS5DJGHm<~5DK<Ok:MIh<F#,6x2;;aJx8?SkD3R;VVSoQT5D!#~}
~{<FKc;z5D7"U9#,JG#:~}
~{Hm<~TZLTL-HK#,HKR2TZLTL-Hm<~~}
~{SoQTTZLTL-HK#,HKR2TZLTL-SoQT~}
~{!-!-~}
~{K-SVD/9;1#V$2;;a3vOV1H~}C++~{!"~}Java~{;rU_FdK{5DSoQT8|:C5DSoQT~}?
^~{:zK50K5@~}^
dogdog 来自 ：
我是从DELPHI 转 VC++ , 实际上用VC++作的界面可以比DELPHI更强可控性更高运行的速度也是不可同日而语,也有很多人不喜欢象void* 这样的代码但是在写算法时,和要求高度灵活性的情况是指针是最强的
Billy 来自 http:// ：
我认为哪种工具实现功能更方便更容易更少用时间就用哪种工具，BCB、VC随你高兴。
阿刚 来自 http://guney.126.com ：
各位老鸟:
你们的讨论让我这个 菜鸟感到 一头迷雾.我正在学c++,难道我要drop吗?
我上大二,很喜欢programme.刚学了c,我不是计算机专业so没学pascal.我想
没了pointer的c就不是c了.它很灵活,很易出错right,但他的强大应该无人质疑.
我自学了一些pascal,好象也有pointer.
我很喜欢c so 我也喜欢c++,为了考试我要学c,各位老鸟,有谁能给我一些指导.
阿刚 来自 http://gunney.126.com ：
tata:
你好！
Charles Petzold 的Programming Windows 哪儿可以下载？
如有可能，可以把他放到你的主页上吗？
感谢涕泞
阿刚
呆鸟 来自 http:// ：
很多程序员,包括一些使用DELPHI的程序员,认为DELPHI 和VB只不过是
改改属性的开发工具,这其实只是他们对DELPHI的不了解,很多人喜欢DELPHI
就是因为他可以改改属性就可以写程序了,但也有人用DELPHI写程序从不用
任何VCL的控件.我觉得使用DELPHI没有两三年以上的经历,是不可能了解
VCL到底是什么的.包括写超级解霸的梁肇新先生,他对DELPHI的评价也不敢
叫人苟同.
如果你想写一个改改属性就可以的程序,用DELPHI没问题,如果你想写一个
和VC具有同样效率和大小的程序,用DELPHI 绝对也没有问题.可以毫不夸张的
说,真正用一种语言可以写任何程序,而且不算太复杂的话,只有DELPHI.
这是BORLAND 的一惯风格,不管你是一个什么样水平的程序员,你都可以用
DELPHI实现自己写一个好程序的梦想,写程序应该是一件愉快的事,这就是
BORLAND 想实现的,也是我用DELPHI的唯一原因.
feldspar 来自 http:// ：
It's unfortunate that many people still think of Pascal as a beginner's language, fit for little more than hobby applications. This is probably due to the irrational Western mentality that if something looks complex, or if it is hard to understand, it must be powerful. Bear in mind that a high-level language like C/C++ or Pascal is just an interface to assembly language that is easier for humans to understand. Each language has a few small advantages over the other, but ultimately an application written in either language is transformed into a final assembly language form. The only differences lay in how this transformation is accomplished by the compiler, and Delphi's compiler can create assembly language that competes with the best of them.
This is a truly opinionated and arguable statement, but Delphi's Object Pascal is a much better language than C/C++ for two reasons: It is not as arcane, and it is much stronger typed. While it is possible to write easily understandable code in C/C++, it is just as easy to write code that is completely unintelligible and unmanageable.
softarts 来自 http://softarts.home.chinaren.com ：
记得在inside vc++中看过这样一句话，以后的程序员会分为两部分，一部分写底层的组件，另一部分负责把这些组件装并起来，以我看，vc程序员是前者，vb,delphi,c#,bcb,java程序员是后者。我现在因为人手的关系，既干vc程序员的活，也干vb的活。感觉到缺了前者或者后者，这个程序员的世界就不完美。
Bux 来自 http:// ：
I don't agree with zhangxiuyong's opinion more. In fact, BCB is the same as Dephi and VB in programing method.Most of there tasks are to drag and drop ActivX(OLE).Although this method offer a lot of convinience to programmer,but many flexibility are given up as well.If you can weild vc deftly,you can find real happiness in programing with using vc.Maybe it is hard to learn and use it.
In light of hfgh's opinion, I think he is right.But the development in this direction can't depend on serveral talks or articles expressed in internet or periods.It need systematic education and traning.You can find that there are many R&D and Traning Institutions in big comapnies of U.S.A and Europe.When you turn your eyes into inner side,these phenomeion scarcely emmerged in Chinese comapnies. And the education system haven't done such tution and dosen't have ability to do such work.
dch 来自 http:// ：
我头疼
Mygod 来自 http:// ：
我是一名老C/C++程序员，从DOS的TURBO C 到VC6.0干了8年，当时主要集中在
单片机与工业控制软件，（MIS极少干，不敢乱加评论）一个痛苦的感觉，很累，很累！！！。但是最近用ATL编COM一秒在局域网传5000个变量。发现达到性能的工具还是VC,但是特殊的场合并不能代表整个软件行业。它耗去我一个月的时光（本人脑力不济）我不希望更多的人走我的路，希望某一天大家能用java或更简单的工具解决问题。
天天有鱼 来自 http:// ：
兄弟们，
大伙儿，辛苦了。讨论了这么长时间，一句话，
就是那种语言能主宰这个世界，那种能活下来。
我们程序员该采用什么以适应未来的软件世界。
我的答案很简单：
跟着微软走，没错的。
说实话，我对微软也没好感，但是要承认微软确实有其他公司
所不能比拟的优点所在
要不什么Visual Stidio ,怎么能流行一世，
要不微软在操作平台，IE上能风光一世。
在对于未来的软件走向而言，不错其他公司有着他门所独特的
想法，但微软的想法更多，
要不，微软怎么会推出C#。
如果是想做专业程序员的，请立即学C#， 在未来的几年内，
C#的风头绝对盖过java.
有句话： 跟着大公司走，不会错的。
另外：
插一句： 对于自由软件只能是程序员玩玩，不能主宰世界的。
未来的用户只能是傻瓜型的，对他们而言，谁给与
简单和方便，他就跟谁。
vclearn 来自 http:// ：
我编程最先用的是DELPHI，本来用得挺好，可现在我程序的上家改用VC了，不再为我提供支持DELPHI的COM。我也只好去学VC，可是进展很慢（这才发现DELPHI的好处），买书N部，居然连书上的例子也运行通不过。所以我对第一篇文章的这句话最感兴趣：“果你原先用Delphi(Object Pascal语言)，现在想改学C++，应当先用C++Builder。熟悉的界面和相同的框架会让你的转轨事半功倍。 ”真的又要挤出银子了吗？请教诸位对此有何意见，请教dogdog大虾有何经验传授小弟。我是做工控开发的。
阿刚 来自 http://gunney.126.com ：
各位大虾，小弟近日编一小程序，在vc中选console。
已经
#include<windows.h>
但调用API函数GetMessge,TranslateMessage,DispathMessge时
总是讲
-------------------Configuration: WinHello - Win32 Debug--------------------
Compiling...
WinHello.CPP
D:/mydoc/WinHello/WinHello.CPP(64) : error C2065: 'GetMessge' : undeclared identifier
D:/mydoc/WinHello/WinHello.CPP(66) : error C2065: 'TranslateMessge' : undeclared identifier
D:/mydoc/WinHello/WinHello.CPP(67) : error C2065: 'DispatchMessge' : undeclared identifier
Error executing cl.exe.
WinHello.obj - 3 error(s), 0 warning(s)
在borland c++4.0中也是一个问提
不知道是什么问题
盼望各位大虾的援助
magicwizard 来自 http:// ：
阿刚你好,请把源代码寄给我,我来看看.
skyriver 来自 http:// ：
Dear friends:
where i can get more information of c#?
through 来自 http:// ：
中国现在的软件行业主要在做什么，OS，OFFICE 是美国的，除了数据管理大概没别的了学一学BCB就行了。
阿刚 来自 http://gunney.126.com ：
首先谢谢你magicwizard
2000.9.10 15:57
各位大虾上次的问题真是太stupid了，message竟忘了a,太不好意思了
这次我想问的问题是borland c++ 中有一个模块定义文件(.DEF)在vc
类似它的功能是怎么实现
上次的问题解决后编译可以通过而连接时出了问题
在vc中：
--------------------Configuration: WinHello - Win32 Debug--------------------
Linking...
LIBCD.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
Debug/WinHello.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
WinHello.exe - 2 error(s), 0 warning(s)
在borland c++中：
Linking proj0000.exe:
Linker Warning: Attempt to export non-public symbol WindProc
Linker Error: Undefined symbol OwlMain(int,char far*far*) in library file E:/BC4/LIB/owlwi.lib in module winmain
不知如何解决：
渴望帮助
ILoveVC 来自 http:// ：
看了以上大家的讨论，我觉得其实工具是次要的，关键是人的需要。这就像飞机与汽车一样，你觉得飞机好还是汽车好？这个问题没什么意思。我初学编程的时候用的是vb，那个时候，快速、简单的实现某一功能是我的目标。现在，我使用vc，因为用它更能表达我的个性（程序设计对我来说是门艺术，只为了做软件去买和街上卖白菜的有什么区别）。甚至，有时候为了追求速度，我都想使用汇编。如果要我开发因特网程序的话，我会毫不犹豫的选择java。所以说，关键是要看你的需要，c/c++在几年内是不可能淡出的。
yy0933 来自 http:// ：
select vc or bcb or delphi?
bcb is uesful???
vc is very hard!
阿刚 来自 http://gunney.126.com ：
各位：
我由一个问题
在vc中用class wizard加入消息处理函数
是自动在消息映射中加入
如
BEGIN_MESSAGE_MAP(CAboutDlg, CDialog)
//{{AFX_MSG_MAP(CAboutDlg)
ON_WM_LBUTTONDBLCLK()//就是这里
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
同时在头文件中加入
afx_msg void OnLButtonDblClk(UINT nFlags, CPoint point);
得声明
我想问编译器怎么知道 响应 ON_WM_LBUTTONDBLCLK 消息得函数就
是afx_msg void OnLButtonDblClk(UINT nFlags, CPoint point)
望各位老鸟给予解答
小弟先谢了
果子 来自 ：
"同时VB7.0全面支持direx8.0". 麻烦去问一下做过游戏的人(我也算参加过商业游戏
的开发). VB再支持direcx 8.0也还是VB, 多数游戏开发者都是一笑了之. 现在的视频游戏有时还要用inline assebmble.不是号称可以"支持"某某就能涉足一个领域的.
DEV 来自 http:// ：
不要单从性能速度上比了，工具就是工具，运行速度和开发速度永远是矛盾的两方。从理论上说，机器码的运行速度最快，是不是要用机器码开发程序？爱用什么就用什么吧？用VC也好，CB也棒，大家静下心来写程序吧！想比一个高下，好！立一个项目，一波VC，一波CB、谁的开发出来的好就成为在“朝”一方，下一个项目就用谁的开发工具作为正统的开发工具，在“野”一方也不必泄气，继续努力，写出更好的东东来，争取下一个项目恢复正统。这是国际标准竞争建立的惯例。如果真如此的话，我加入那波无所谓，锻炼水平。可惜国际上不为哪个商业工具好这些东西争论，人家为没有还建立的东西竞争，国际上写出的C语言相关的程序大多是很多工具都可以编译的，而且还跨平台。
alen 来自 http:// ：
各位讨论得好热闹呀，但我觉得大多数人的意思都有一定的主观性，其实每一种开发工具的存在都有其存在的理由，就算它会被过时它也已经有了存在的价值。
要评论哪种工具更好显然是一种非常不明智的想法，因为每个工具都有其自身的定位，如果说用来教学或作快速开发，那时CB/Delphi肯定要比VC更好，但如果真正开发大型软件或是系统软件，那么VC应该是首选。而且对于每一个程序员来说，如果他自己已经习惯了一个工具，那他肯定会认为这个工具是最好的。
如果从客观来评论，显然开发效率与代码质量是不可调和的一对矛盾。曾经有人说MFC是如何的臃肿，但如今呢，更臃肿的好像成了先进的代表，说实话，VCL的确非常好，但也的确太臃肿，它设计得太好了，以至于很多的东西根本就用不到，却也非得加入到执行代码里去。MFC却相反，它只是对API的封装，尽管也支持很多先进的技术，但毕竟要程序员自己却做很多事情。
但对于一个很精通SDK的资深程序员来说，难道在他已经非常熟悉了MFC后让他再来尝试用VCL来写程序吗，他会对那些所谓的事件（其实就是消息处理）有特别的兴趣吗。我想他只能会在VCL中借鉴一些先进的思想来改进他自己的代码，因为VCL毕竟不是完全可以拿来的。
Cedric 来自 http:// ：
VC、CB、Delphi、Java、C#孰优孰劣是否讨论的太多了，本人乃一菜鸟级程序写家，也曾经为这些语言的比较大伤一番脑筋，比来比去，觉得这也好那也妙，大有寝食不安的的感觉，某一日，静思之下才领悟到：语言毕竟是一个工具而已，就象吃饭用筷子好，还是用刀叉好一样，看你吃什麽样的菜了，去吃西餐偏要用筷子，去吃中餐却要用刀叉，你能吃出效果吗？所以，依据你的客户对项目的性能、功能的要求及语言的擅长来确定使用何种语言是否更好？再者，我们为什麽非要在一棵树上吊死，集各语言之所长共同完成任务才是当务之急。
谁见过使用单兵种就可以赢得战争的，请站出来。
此乃本人愚见，仅供参考！
Fang 来自 http:// ：
我认为比较那种开发工具好是愚蠢的行为。
为什么要比较？
为什么你要说哪一个更好？
因为你要说服别人！
因为你觉得你用的最方便最顺手的就是最好的！
决不能把自己的观点强加于人！
物种还有多样化呢！“存在的就是合理的”！
自己用的最顺，开发最快，你就用它，没错！
为什么和别人争执不休？
所以我基本上只用c/c++，因为别的我不熟！别无选择！
谁说c/c++开发慢，那是你选择开发工具不正确！
数据库应用程序pb难道不好吗？
电子商务的跨平台用java也是很理想的嘛。
中国的别尔盖次 来自 http://www.sansitech.com ：
我认为,这两个开发工具都不错!
alen 来自 http:// ：
有人提到了C/C++应该退休了，我非常不同意这种说法，其实那些开发出Java，C#的程序员们心里最清楚不过了，C++能做什么，C#又能做什么，如果说C#可以替代C++的话，那么以后还会出来更容易的C#++，到那时可能你只要写两三行代码就可以生成一个“完整”的应用了，那样的话，程序员就真正很轻松了，或许人人都会写程序了，就像人人都会看电视一样。那么谁来做电视呢？！只有那些“笨”得只抱着C/C++不放的傻瓜程序员们吗？！
好像又有人说MFC要过时了，因为Microsoft内部有人在开始写WTL了，我想举这个例子的人应该看过WTL吧，要不然他/她怎么会说MFC要被淘汰了呢？！反正我是看不出WTL比MFC有哪些地方更RAD了，相反，要真正理解WTL，还得理解ATL以及多重继承，而多重继承在MFC里都没有用得，正是因为它太复杂了！！！
梨子 来自 http:// ：
to 恶魔吹着笛子来
我觉得你很牛啊, 能不能讲讲JAVA在embedded system的前途,我是干那行的.
lxsuperman 来自 http:// ：
大家好。
我想问一下各位老鸟一个问题：
我在MFC中如何用C的标准的文件的输入输出：
我在程序中加入了<stdio.h>
但，用::feof(f)时VC++告错，而变成feof(f)就行
不是‘::'是全局运算符吗？而，feof()这个函数在C中定义为全局的吗？
为什么会这样？请解答，谢谢！！！！
果子 来自 http:// ：
“C++应该是JAVA”，这句话是在JAVA的程序员中很流行的，意思是说如果JAVA早出二十年，那么就不会有C++了”
错误之极。面对二十年前的硬件水平，JAVA没有说话的资格。
Neithardt 来自 http:// ：
TO 果子：
或许你该看一下C++的来历。在当时C++并不是C的唯一改进，在当时除了C++外，还有很多的C的改进版本，但是为什么C++会那么流行，就是因为所有的C程序都能在当时C++的编译器里通过，换言之，所有的程序都不需要修改，而且C++的思想更切合实际。
JAVA的优势在哪里？就是平台无关性。我们整天说C的移植性好，但是在这方面，C的优势绝对比不上JAVA。
固然，在那时候的硬件水平上，能否使用JAVA还是个问题，但是“C++应该是JAVA”这句话形容的是JVAV对C的改进远比C++要大。JAVA并不单纯是一种编程语言，更是一种思想。
抱雪 来自 http://bcbtop.126.com ：
我是用BCB，就为比较简单，对于MFC，说句实话，还不如OWL，如果不是M$的东东 ，我估计早就消亡了，JAVA虽然好，但C、C++也不会消失，WIN2K不就是用ANSI C（还不是C++）写的？所以，我认为什么开发工具并不重要，主要是能把东东按时的赶出来，这才是最重要的，有人会说，这和买白菜有什么区别？那也是你把自已看得太高了，你就真的比买白菜高一等？
Quiet 来自 http:// ：
嘘。。。
AutoAsm 来自 http:// ：
各位好象对BCB的评价不是很高。
我是用BCB的程序员，现在也在学VC。我不知道是“弃暗投明”了，还是“弃明投暗”。
很多人考虑编程的灵活而用VC，我认为理由不充分。也许你不相信，前年我还在使用Quick C编写WIN32程序，并且我还会用汇编语言编写WIN32程序，这恐怕是各位VC程序员所不及的。用API函数需要深入理解WIN32程序结构。
但是写软件毕竟是一项工程而不是科研，也就是说，无论用什么工具，能在最短的时间内按需求分析的要求交付产品即可。
使用BCB可以大大缩短开发周期，节约开发成本。
但是BCB并不是全能的，它本身对系统要求比较高。BCB的编译速度和智能帮助的响应速度远比VC慢。
但VC的缺点也是显而易见的，用VC开发复杂的GUI是件痛苦的事情。VC在设计时给程序员的帮助实在太有限了。所以，有相当多的VC开发者转向BCB。
我之所以学习VC，是基于两个考虑：1.毫无疑问，VC是当今最流行的开发环境之一，任何软件开发者都应该会用。2.用BCB的编程模式编写的模块内聚程度不够，在做大项目时感到力不从心。
但是无论如何，BCB确实是一个重量级的选手，也正是因为BCB的存在，我们有理由相信，VC7是值得期待的。
WebDB 来自 http:// ：
呵呵，大家讨论了很多都是开发工具优劣，我想应该根据任务的不同选用合适的语言和工具。
其实现在程序员不应该只停留在语言的使用上，应该向更高层次发展，多看看软件工程等资料。深入学习面向对象的思想，看看UML，熟悉项目管理的东西。还有CORBA，这是与语言和平台无关的。
总之有很多东西需要我们去学习的。
菜鸟看天下 来自 http:// ：
我对于MFC的开发过程搞不蛮清楚，好象是由一个小组负责的。所以我一直怀疑，虽然MFC是由微软支持的，但它是不是带有很大的个人色彩呢？(虽有版本的变更，但都未脱离其原形) 正所谓众口难调，如果你的思维方式与这些开发人员合拍，当然为其叫好，而有人更偏爱“搭积木式”的VB，也只是个性使然。
那些才华横溢的原创者不过是按自己的思路提出了一种解决方案，却引得我们殚精竭虑^_^ 不过除了个人喜好之外，还是应该根据手头工作拾取不同的工具。
唐一均 来自 http://airesearch.yeah.net ：
在次的都是专家，作为普通的一个程序员，只想说几句实在的话。
评论delphi，VC，BCB这些开发工具的专家们，有多少是精通所有这些
工具的？
评论它们，各自又站在不同的水平和立场上，有几个评论家替我们这些
一年到头苦干和学习的程序劳动工人想想的？
作为一个程序员，谁都有需要不断提高自己的过程，一回生二回熟，
我自己就在不懂VC的情况下，边学边干，用了2个月开发了一个不小的数据库软件，开始时候真是一窍不通，可是在意志的坚持下，硬是坚持了下来，可是我们单位关我的领导是不懂计算机的，说我一个月就能编完，现在用了2个月就很不满意了，我周围的同事没一个懂VC的，一般用Delphi，于是也顺着领导发表高见，说是delphi如何的好，编译出来的代码效率比VC的要高，而且他们也不开发，整个中心就我在开发程序，你看到这些觉不觉的好笑，可是你要知道，2个月要学出VC并用它写一个看的过去的程序，最困难的不是技术，而是时间太紧了，在这2个月内，我还发表了2篇VC的文章，要知道，我不是什么天才，我也只有24小时一天，写上面这些，不是要标榜自己什么，是要告诉大家，尤其是不断奋斗中的程序员们（专家不在此列），压力和困难你是要习惯的呀，否则不要作程序员。
言归正传，什么编程工具好对并没对什么都了解的初级程序员而言不重要，重要的是尽快多学，尽快提高水平，可以这么说，什么东西都有个寿命，如果你什么都了解并不断的学习，那么你就一直不会落后。
等你是专家的时候，请不要骄傲，因为你还有太多的要学，更何况你的生命才有多少年？
我不是最高级的程序员，我只在学习中体会快乐，我的水平比不上很多人，但我知道如何用最短的时间去研究和学习新的事物，这是需要靠智慧的，提高自己认识事物的深度和广度，这样你的人生才没白过，否则就算你精通所有的编程语言，水平高的怕人，也编出了几个相当成功的软件，可是你一样要过时，一样只是个知识库，相对于人类社会和广阔的世界，你还是只知道芝麻大那点。
最实际的问题是，老板不考虑你正在学什么，也不考虑你学会了什么，以后对公司实力有多少帮助，老板只要你为他快速的卖命，有点懂计算机的老板还有时候要考虑一下代码质量。在我们单位实际应用中，出现这样的问题，delphi学起来快，马上就开始编，可是质量很差，最后导致项目失败，为什么这样？不是delphi的过错，是那些程序员经验不够，为什么经验不够，其中一个原因，我想是过与依赖傻瓜型的工具和不考虑软件工程，我想如果一个程序员能有那种类似研究MFC的毅力的话，用其他工具也一定会用的很好。
保守党 来自 http:// ：
印度发家的故事说明，语言的问题有时的确关系到一个国家软件产业的兴衰，而不是象前面有人说的那样无聊。
80年代，与中国一样，印度也开始推广计算机教育，他们选择了cobol作为主要语言。当时，在西方，这一语言的应用还很广泛。然而很快，c就开始风行了。西方新的程序员无不以掌握c为其主要任务，很多人忽视了其他语言的学习。
90年代中期，y2k问题开始困扰西方银行家们。他们才发现，解决系统中的y2k问题需要大量熟练的cobol程序员，而西方已经很少有了。正是这时候，印度的cobol程序员开始涌入硅谷，专门负责阅读和修改那些长年积累下来的cobol程序，清除其中的千年虫。同时，更多的程序被送往印度，直接在那里修改，再送回来，这就是印度软件业发家的开始。
其实，中国软件业落后的原因，对比一下便知道：当年，人家说，basic是最适合初学者了，于是我们就推广basic；后来，人家又说，pascal才反映了结构化，于是我们又教pascal；再后来，人家又说，“真正的程序员用c”，于是我们一涌而上地教c；再后来，便是c++、java、(C#?)了。这样跟着潮流走的结果，就是我们永远落后于潮流。一种东西还远没精通，就在等着新鲜玩意了。“反正这个过时了，等新的吧”。
“浮躁”，这就是中国软件业的毛病。总想抓住最先进的东西，不顾自己的国情。等你刚刚把它摸熟了，人家又有更先进的出来了。
如果把硅谷的先锋们比做淘金者的话，那么印度人则象是送水人。他们用水换来金子，于是跟那些淘金者们一同发了。而我们中国人呢，更象是一群乞丐。淘金者们走到哪里，我们便跟到哪里，指望从他们鼓鼓的钱袋里掉出金币，让我们拣了去，纵然不能发家致富，带回家也可在父老乡亲面前炫耀一番。
所以我认为，这个语言的问题，既重要又不重要。如果说印度人当年坚持教Cobol是因为“高瞻远瞩”，打死我也不信。但正是他们这种执着，使他们得以精通Cobol，使他们成了不可替代的“Coboler”。这正是“一分耕耘，一分收获”。而中国的程序员们，总是在寻找“耶里娅”，却白白荒废了大好的时光。
所以我认为，在选择自己的方向时，当然要做些判断，比如技术的先进、市场的需求、未来的发展。可是一经决定，便不宜轻易更改。我们还是埋头苦干吧，不管你的语言是什么，下苦工夫成为一个精通者，并且用它做出一些成绩来，你就不会“过时”的。君不见，那些fortraners如今都已成了教授、博导了吗？
来自 http:// ：
保守党, tell you a truth,I have a firend who lived in US,He is a good Coboler..hehe...but now, he have to learn VC++,why?
do you like these the fortraners to be your teacher??hehehe
唐一均 来自 http://csharphelp.yeah.net ：
对保守党的高见，我介绍一篇文章，保守党最好读读
我在工作中，接触到印度软件公司开发出来的软件：整个体系架构非常清晰
，按照我们的要求实现了全部功能，而且相当稳定。但是打开具体的代码一看，
拖沓冗长，水平不咋样。我们自己的一些程序员就有怪话了，说他们水平真低。
但是！印度人能够把软件整体把握得很好，能够完成软件，并得到相当好的设计
文档。而中国人在那里琢磨数据结构、算法，界面人员就还没编码就想着是Outl
ook式的还是VisualStudio式的界面。到最后就成为Code高手，对某些特定的开发工具精通，但是就是不能保证能够把一个软件稳当、完整的开发出来。
举个简单的例子：软件中需要一个列表，用来表示我们处理的事务。该类表
在业务繁忙的时候将变得很大。中国人就用双向链表，抱着《数据结构》书在那
里写链表的类。印度人开了一个大数组，然后就开始干。为什么印度人不用链表
，他们说：1、你们给出的设备(小型机)，最少具备512M内存，浪费一些没有什么。2、数组方式访问方便、效率高。看出了一拿到东西就吭哧吭哧作Code，和好好进行软件分析的不同了吗？
正好前几天我有几个同事从印度回来和我们交流,那家公司是CMM4级公司.我
感受的几点:1,流程重于项目2,QC(就是QA)独立于研发部门,专门检查研发部门的
开发流程是不是按照既定流程走.如果QC觉得流程不对,他会直接上报高层,项目
定就此停止.3,所谓的项目经理(PC)一般也是从编码人员升上来的,并不是所谓的
不懂技术,一般都至少有四年以上的经验4,PC主要就是制定开发计划,负责协调,填写各种表格.5,所有的东西(包括草稿)都有文档.6,详细文档要求达到只有这个文档就可以编码的程度,一般写文档时间占60%,编码时间极少7,有各种详细的review(同行评审),项目组内的,项目组之间的,客户的...8,计划很详细,的确能达到小时级,但是实际情况还是误差比较大,所以他们也有加班.先学习UML和Rose以及RU P，不要总是要找着证据。在中国的软件开发水平下，很难给你一个好的例子，OK？中国人总是要看到一个东西有了试验田，而且稻子长得好，才换稻种。要知道在国外上述的软件开发模式的应用，大可以看看Rational网页上的story。Justdoit! 一句话，中国的软件开发水平低得很。赶不上印度人，印度的软件公司可以
让高中生编代码，它的软件工程水平可想而知。当然，你如果是个很牛的程序员
。估计够呛，因为中国的气氛中，很牛的程序员都很难接受软件工程的。你可以
测试一下自己，看看自己适不适合现在学习软件工程：1、你是不是不能忍受一个
编程序不如你的人做你的项目经理？2、你是不是觉得你的老板对客户吹牛皮、夸
大自己而感到不舒服?3、你是不是一个拿到一个需求脑袋里第一念头就是如何实
现的人？4、你是不是很崇拜Stallman，Linus，很讨厌Microsoft?5、你是不是曾经在深夜编码的时候，突然感觉到一种乏味，对Code的生涯感到一种无趣？以管窥豹──印度神话作者："Kino"我们现在处于深深的自卑当中，感到中国的软件工程水平的低下已经是牵涉到民族劣根性的问题了。1、他们的软件教育水平：我们招聘印度人，给应聘者出了一份与国内差不多的试卷，有基础概念和编程题目。等到他们完成后，我们这些中国的自认高手惊呆了！他们的编程题目简直象是抄袭的?nbsp;?nbsp;程序结构，注释，变量命名就不说了吧，全部都是极其类似！反观中国的牛人、高手，每个人有自己的一套。到了新的岗位，先把前任的程序贬损一通，然后自己再开发更多的问题的代码来代替。我的公司统计，一个软件中有4个以上CSocket版本，每个人都觉得别人做得差，自己再搞一套。中国人 ，就是这个样子，还会辩解说“我们这样有创造性”。
其实软件发展，早就走过了求伯君那个编码英雄的年代，程序员已经是个坐
办公室的蓝领了。你具备拧好一个螺丝钉的能力就可以了。Code是最低级的事情
了。2、他们许多公司的项目经理根本就不懂技术。中国的项目经理如果不能在技
术上压服下属，那么下属将与他搞鬼，越是高手越喜欢搞鬼，根本不知道作软件
的终极目的是从别人兜里掏钱，而在内部搞不团结。技术高手都会纠集一些对他
技术上崇拜的菜鸟，与管理层作对。而印度的软件经理根本就不懂正在做的东西
，许多甚至直接就是MBA，或者是领域专家(工业设计、地理专家等)，而不是编码 的专家。但是却能够领导大群素质良好的程序员把工作做好，没有内部不团结的情况。许多印度的程序员加入一个公司很长时间，都不知道自己整天编的代码是干什么用的。给他们的任务可能就是一个函数的声明以及该函数要实现的功能。
我们呢？3、他们的编程人员的流动率达到30%!他们的编程人员流动率(包括内部
项目之间的流动)高达30%，可以想见他们的文档水平如何。他们的产品不依赖任
何一个人，谁都可以立即辞职，产品的开发还是会正常进行。而中国，是老板怕
总工。技术骨干拥兵自重，抗拒管理。任何制定好的计划，都有可能被技术人员
推翻或者跟你消极怠工。4、他们的开发计划能够做到小时级别。如果一个印度公
司的项目经理没有上班，那么他的下属将可能不知道作什么。他们的计划一般都
定到天，每个基层开发人员每天的工作量就是8小时。而我们能够给出月度计划的 公司就很少，而给出的月度计划要么不可能实现，要么就可能被取消。开发人员 被初略的给个任务，他在月初，可以慢慢琢磨是做成什么样子，然后上上网，聊聊天。到了月中和月末，就开始熬夜编码。
看到每年，从各大高校不尽牛人滚滚来，我们是不得不要召人，同时又是
不抱希望。我公司现在有意以后将核心软件开发外包给印度公司，中国人？做做
界面吧，中国人做界面会极尽奇技淫巧，搞得花里胡哨的。BTW，我公司非外企，
大家不要误会我们有什么种族歧视。但是我们现在就是对自己歧视，自卑得很。
中科院那么多研究院，连个能用的操作系统都搞不定。北大开发一些东西，比如
什么青鸟CASE，就是给一帮人评职称的。杨芙清院士整天搞来搞去，搞出了什么
东西？B大，T大的人最难管理，牛得看不见人。中国的程序员骂微软，追Linux是全世界最狠的，可是我们除了汉化Linux，做了什么东西出来。CDE是瑞典人写的，Linus是芬兰的，GNome是墨西哥人写的。哎，我们曾经是多么的瞧不起印度人。
learner 来自 http:// ：
各位前辈：我是一个计算机系大二的学生。现在我正在自学数据结构，同时在自学操作系统。 我一心想成为数据库程序员，但我又对c++感兴趣。
在数据库方面我听说vc++不行，故我现在想先学c++builder，以后在学VC++。不知我的选择对
吗!不对，能指点迷津吗？(学c++builder有前途吗？)
cd 来自 http:// ：
to learner:你的选择非常对
Passenger 来自 http:// ：
各位，我在微软工作，提供技术支持，不是开发者，所以有可能说的话不适合开发者.
但我想说我在微软的所见所闻。不管局外人怎么对微软look small, 怎么捧非微软的东西，我想微软的东西确实是做得最好，最规范，bug比率（不是绝对数）最少。微软的内部文档层次结构非常分明，非常便于查阅。
有人认为微软非常的傲慢无理，其实微软在自己的customer面前非常的谦逊。我们提供product support 的在接到客户请求后必须在一天内做出反应，不管今天又多忙。而且必须做到使客户满意，否则我们不能结束这个CASE.我们做得很多技术支持是第三方软件，应为这些公司不愿支持，把责任推给微软，我们也只能做。
BTW,我们的技术支持是全IT界最好的 (ZDNET评的）.国内的客户有可能享受不到如实到位的技术服务（没多少人用正版）。其实大家想一想，一面不付钱用这个公司的
产品一面骂这个公司时间很不公平的事.
其实在微软内部你一点都不会觉得公司要被分了。大家都很乐观我们能胜诉，因为微软的确是在为客户提供最先进，对客户最有利的产品。
111 来自 http:// ：
的确
保守党 来自 http:// ：
唐一均贴的文章拜读啦,不过我想文章跟选择哪种编程工具没太大关系.
中国的软件工程确实很差,但这主要是因为工程管理人员素质太差,不能怪程序员.如果组里有很多编程高手,却不能协调一致的工作,那只能说明组长的管理有问题.
文中的其他东西就更不敢苟同了,比如那个数组和链表的例子:"1、你们给出的设备(小型机)，最少具备512M内存，浪费一些没有什么。2、数组方式访问方便、效率高。"是根据具体情况而定的.比如,你的计算机上总不是DOS操作系统吧,你可能安装了一些其他的软件,要同时工作,这时,512M就不见得还是"浪费一些没有什么"了.或者,这个例子倒可以说明中方(业主)在系统规划(管理)上的无能,用512M的计算机来作这种用途,对自己是浪费,对软件承包方却是个大空子.
"3,所谓的项目经理(PC)一般也是从编码人员升上来的,并不是所谓的不懂技术,一般都至少有四年以上的经验" VS "而印度的软件经理根本就不懂正在做的东西，许多甚至直接就是MBA，或者是领域专家(工业设计、地理专家等)，而不是编码 的专家。----which is true?
至于作软件的"终极目的"是什么?这个问题确实让人挠头.你说"作软件的终极目的是从别人(客户)兜里掏钱".我却觉得,掏客户的钱固然重要,可是陶来的都落到老板的口袋里也不行啊.从老板的口袋里掏钱给自己也很重要啊.
其实,"经理","系统分析"和"程序员",只是生意上合作罢了,各司其责,大家一起赚钱.不要总是一副"国家干部"的派头,仿佛什么问题都是下属不听话造成的.
至于编程工具的选择问题,我的意思当然不是说"Cobol是最好的,你们不用学别的了".而是说,我们中国人目前既然不能主宰这一市场,那就最好是听天由命了,把对你有用的学精学深,比你追着市场却永远落后于它要重要的多.
changning 来自 http://redpower.myrice.com ：
各位谁能说自己Delphi,VC,BCB,JAVA,C#都一样十分精通，如果各位没有这样的实力，评价什么都没用，抓紧时间学习吧，C语言的指针好，功能强，但是很容易导致错误，据说在国外，资深程序员轻易不会用它，但是偏偏我们的一些人却认为这才是高水平的表现。简单是一种美，不要认为BCB,Delphi没有能力开发出稳定的东西，这与人的素质有关，不要认为BCB兼容性不好，没有再BCB1中兼容BCB5的控件，可是VC1兼容VC6的程序吗？既然听说Delphi有能力开发VXD,WDM程序，那么Delphi和BCB也是一种和VC同样万能语言。不要告诉我基于MFC的程序可以在任何编译器上通过，实际上由于Windows的特殊性，以及VC根本不能完全兼容ANSIC/C++标准，MFC程序根本离不开VC和BCB。另外居然自认为高手的人认为VC可以编写操作系统的核心（不是VXD/WDM而是全新的操作系统)，你认为可能吗？
leeseon 来自 http://leeseon.yeah.net ：
我是这两者都用过的，只能说各有千秋，想绝对的说谁好谁坏。我看任何人都不能下一个武断的结论的。
不过我今天想讲别一个问题，为什么我们总在争论外国的工具中谁好谁坏呢？难道就不能有一个中国人自己的开发工具吗？可能也有人想过就觉得可能性太小了。因为一个开发平台可绝对不是任何人说作就敢作的。可是我却知道有一群人，为了这个几乎虚无的目标奋斗过两年了，他们的目标就是做中国人自己的VB－－－－一种有着VB语法和解释性语言优点和C＋＋的真正面向对象的类的概念，而且计划有一些网络功能的语言（HB＋＋）.....这绝对是一个大项目。现在已经有了一个可以将一些VB代码直接拿来执行和实现类的多态，继承功能的核心了，而且比JAVA的速度起码快10倍。还有很多工作要做比如界面和网络功能等等。详情可以看lifesoft.yeah.net上的内容。
很可惜，我在为这个伟大的项目奋斗了半年之后，因为个人原因离开了公司，但是我却非常关心着这个伟大的项目。不知各位有什么想法？
可以和我讨论，并且如果对具体情况感兴趣，希望您能加盟这个团体。联系方法是
hysoft@public.xa.sn.cn
regale 来自 http:// ：
天天有鱼，你是一个脚踏实地的人，我虽然也厌恶微软的东西，可是不跟他还不行！呵呵，识时务者为俊杰，谁让我还得养家糊口呢？
Small_Fish 来自 http:// ：
我认为选择什么语言并不是最主要的,我认为"开发思想"才是最主要的,语言只是对一
个项目的开发的周期起着有影响.如果你连这个项目都有不知如何去处理的话,给你在
好的开发平台那还有什么意义呢?我学VC++有半年了，我觉得他虽然比较难学，但在学
它的过程中，我学习到许多开发思想和系统函数在别的语言中的运用，使我用别的语言更加灵活．对于一个编程爱好者来说，最开心的事莫过于是创新和挑战．我想用
VC++给我更多的挑战和创新的机会。
Hank 来自 http:// ：
我赞成上一位大虾的说法，说vc好也好delphi好也好。无论什么能够优质、快速的达到预期的开发目标就是好的开发工具。
重要的是涉及什么问题，达到什么目标。如果开发windows下的驱动为了更好的取得系统平台的支持采用ms的vc,但是开发数据库应用，众多的数据库快速开发工具挑一个自己最喜欢用的，能够优质快速完成就是最好的。
随着各种操作平台的迅速发展，用户需求不断提高，平台无关性是应用软件必须面对的问题，所以有了java有了c#。试问、哪个程序员愿意今天用c明天用j后天又用pascal？累不累？
szcooldog 来自 http:// ：
我就是喜欢VC，就是喜欢MFC。你们懂吗？大智若愚、大巧似拙。什么速快开发，让不程序员也能编程，狗屁不通。
我是外行，我只懂汇编 来自 ：
vc 和 bcb 是什么东西
shency 来自 http:// ：
你们怎么一个个都把VC说得那么不近人情呢？不就是一些代码吗？至于那么可怕吗？
告诉广大想学VC的朋友，VC根本就不神秘，每一行代码都有确定的含义。COM啊什么的一下子学不会也不要紧，先把MFC基本的东西搞定你就已经可以干很多事情了。
唯一的问题就是你们的编程风格一定要好，要不然以后我们作同事的时候我要找你拼命的
张文阁 来自 http:// ：
谁可以告诉我VC/Delphi/C++ Builder的价钱哪个贵，哪个便宜吗？当然不是10块钱
2张的那种！
唐一均 来自 http:// ：
回回保守党：）上面贴的文章不是我写的，我也并不赞同这篇文章的
全部观点，在此只是和保守党探讨一下。
*唐一均贴的文章拜读啦,不过我想文章跟选择哪种编程工具没太大关系.
答：编程工具从原理上说并不是决定作用，应该说目前的编程语言功能上
几乎都可以实现，只是有的要转个弯，但一般的功能都可实现，所以一个
成功的软件最重要的地方是系统分析上的，比如用UML工具如Rose建好模，
然后，可以让它自动生成几种通用语言的代码，如VB,Delphi,VC,Java等。
但是，国内一般的开发小组，并不重视这些，至少我们单位是这样，我告诉
大家一个事实，我们系统化了几个亿人民币投资在网络和小型机上，但是开发
应用软件还停留在个人独立开发上，这些人不建文档，不写注释，不搞分析，
可是在选择编程语言上却很有主见，会什么语言就把那种语言说成是最好的，
最后怎么样？我们系统开发了数十个MIS软件，最后几乎没一个真正成功的，
人一跳巢，编的软件就死了，没人能维护好（好象这是报复原单位最好的办法）
总之，在这样一种情况下（不分析，不注解），选择编程语言就有点重要了，
因为要有利于维护。保守党，你不会说任何语言维护工作量都差不多把？
*中国的软件工程确实很差,但这主要是因为工程管理人员素质太差,不能怪程序员.如果组里有很多编程高手,却不能协调一致的工作,那只能说明组长的管理有问题.
答：很遗憾的是，有很多地方，不仅系统分析员有问题，Coding也有问题，更厉害的
是根本没有系统分析员，Coding就充当系统分析了，所以，我个人觉得在国内，coding程序员的概念被扩大了，就是程序员什么都干。你说能不怪程序员吗？
*文中的其他东西就更不敢苟同了,比如那个数组和链表的例子:"1、你们给出的设备(小型机)，最少具备512M内存，浪费一些没有什么。2、数组方式访问方便、效率高。"是根据具体情况而定的.比如,你的计算机上总不是DOS操作系统吧,你可能安装了一些其他的软件,要同时工作,这时,512M就不见得还是"浪费一些没有什么"了.或者,这个例子倒可以说明中方(业主)在系统规划(管理)上的无能,用512M的计算机来作这种用途,对自己是浪费,对软件承包方却是个大空子.
答：对资源的浪费是比较普遍的事情，一部分也是软件开发人员的问题，如我们单位
使用的GIS系统，目前的ARCinfo平台下的GIS用IBM M80,1G内存，可是为了赶新潮，
要用SDE把数据存放在DB2数据库中，开发者说要2G的内存了：），IBM的内存不便宜呀。
*"3,所谓的项目经理(PC)一般也是从编码人员升上来的,并不是所谓的不懂技术,一般都至少有四年以上的经验" VS "而印度的软件经理根本就不懂正在做的东西，许多甚至直接就是MBA，或者是领域专家(工业设计、地理专家等)，而不是编码 的专家。----which is true?
答：本人希望项目经理懂专业，可是不幸的是，本人的上司什么都不懂，这是我为什么要离开国营企业的原因。
*至于作软件的"终极目的"是什么?这个问题确实让人挠头.你说"作软件的终极目的是从别人(客户)兜里掏钱".我却觉得,掏客户的钱固然重要,可是陶来的都落到老板的口袋里也不行啊.从老板的口袋里掏钱给自己也很重要啊.
其实,"经理","系统分析"和"程序员",只是生意上合作罢了,各司其责,大家一起赚钱.不要总是一副"国家干部"的派头,仿佛什么问题都是下属不听话造成的.
答：agree,本人的工资自打进国营企业就没长过，6年了。
*至于编程工具的选择问题,我的意思当然不是说"Cobol是最好的,你们不用学别的了".而是说,我们中国人目前既然不能主宰这一市场,那就最好是听天由命了,把对你有用的学精学深,比你追着市场却永远落后于它要重要的多.
答：本人认为学新的编程语言没什么坏处，因为毕竟你不能认为Delphi=java=C#
毕竟有很多区别，所擅长的地方不同，我们中国人不用去主宰这个市场，因为我们用
不着去做很多别人已经做过的东西，本人认为，人类的智慧是不分国家的，可以继承的就尽量继承，比如Gnu软件，本人相信只要思想意识提高上去，落后就会变过来。
lxj 来自 http:// ：
you are all excellent.
hx 来自 http:// ：
呵呵，几天不见，唐一均你跑这儿来啦，不怕你们领导看见：）有劲发这么长的帖子不好好干活，该打 ^O^
猜猜我是谁 ？
tfp 来自 http:// ：
我在很多的站点上看到这个“热点”问题！
在我看来作为程序员 如果仅是打工，使用那种工具不重要，因为要谋生！
如果自认为是顶尖的高手，可以尝试写一个编译器！ 中国人的编译器。
在这讨论哪种语言更好 ，永远是一个局外人，追随者，我以为
我在想 ： 美国的 印度的 程序员是不是也这么的迷茫，不知该学什么？！
唐一均 来自 http:// ：
hx-----hangxun lao ren jia ma!!!
hahahahahaha
在此显臭了。。。~。*
hx 来自 http:// ：
嘿嘿嘿,Delphi is the Greatese.VC is a good but not great development tool.
nyra 来自 http://go.163.com/~nyra ：
看多了就想说点什么，也许有点一时冲动，但我想有时心底的东西是要有一点刺激才能迸发出来的！
我玩编程时间很短，但接触了很多的东西，其只对我有很太影响的当是perl和php，当我知道perl自己就不是perl产生的时候，（php也是一样，不是用php写成的）
我明白了一个道理。所谓语言，只是交流的工具，计算机语言和人类语言一样，用这种工具和用那种工具并没有本质的区别。我是中国人，习惯于汉语。我用它来表达我自己，用它和人交流，我的朋友也是中国人，他们明白我，这就够了。当我工作后，我接触到外国的朋友，他们来自世界各地，我不能要求他们明白汉语，同样他们也不能要求我明白他们的语言。当然，我们不是就不交流了。我们选择了一种共同的语言--英语。虽然我说的不好，他们也听得很费劲。但是这是唯一的选择。
但是有一次，我学习了他们的语言，英语马上就退出了我们交流的舞台，因为没有存在的必要了。
但是情况很快有了变化，我的合作伙伴换人了，同样他的语言也是我还没学习的，这时英语再次成为我们的工作语言。
我觉得今天我们讨论的问题与我工作中遇到的问题很相似。无论Dephi也好，vc也罢，还是c or java的争论，无非是在说我要就什么语言说话你才能明白呢！
但是，有这样一种语言能通行天下吗？没有。也许有，比如说画图。可是你能想象用画图来表达日常生活的情感吗？或者说你能画出“激情”这个词吗？又或健康？
或许你可以与人约定用某一符号来表示健康，激情这一类的词。可这是叫什么呢？
也许你没有认识到，这就是一种语言，最朴素的表达语言的概念。
语言是交流双方的约定。
回到我们的数字世界，我们何尝不是生活在约定中呢？从机器的01到我们的编程中间有多少不为人知又不可或缺的约定，我们又何必在最后一米的选择上苦苦争扎呢？
我们只是要和我的伙伴交流而已，能够使我们最大限度的自由交流就好了。无论它是什么。甚至我们可以约定出一种新的只有我们自己明白的符号，好比C诞生的初期。这只是我们的工具。
真正的关键是我们在做什么，而不是我们在用什么。
如果没有你合用的东西，为什么不自己做一个呢？我知道这很难，但是不是不可能的。不敢想，何来创造!
wenyy 来自 http:// ：
re:nyra
有一点我不同意，就是
开发语言不但但是一种表示方法，同时也是一种思想，
比如说PERL 和 C虽然语法相象，但是方法却截然不同。
同样不同的开发工具后面也隐藏着不同的开发方法和开发思想。
不知道我这样说是否是有一些夸张，但我自己是这样认为的。
Axin 来自 http:// ：
发语言不但但是一种表示方法，同时也是一种思想，
比如说PERL 和 C虽然语法相象，但是方法却截然不同。
同样不同的开发工具后面也隐藏着不同的开发方法和开发思想。
不知道我这样说是否是有一些夸张，但
cylyh 来自 http:// ：
中国人都太聪明，不愿考虑费劲的事。vc和c++builder的比较有没有用？我想肯定有用。不过制定标准比较难，而且非常难，应该有蚂蚁啃大象的精神吧。作为一个项目经理来说，选择一个语言是重要的事，但除了拍脑门，找灵感外，有没有比较科学点的标准？大比较重要，小同样重要，小的积累成大的突破，语言各个点的熟悉才有选择时的不头疼。如果大家都把人云亦云的精力拿来做自己有把握比较的点的比较，一万人的点会聚之后答案也就出来了。做人做事一样的吧，大的观念有突破，就看不起钻牛角尖的，其实是应该并重的。抬起头来看路，也要踏踏实实走路。
说软件工程重要，一时大家都奔宏观而去，但观察国内，有几人能对一种语言透彻了解并写出一本好书来。有独立的见解，能找到独到的课题，并能独自（会合作）研究出成果来，是人才。中国的教育体制害了几代人呀！
光说不练假把式，让大家见笑，原谅。
蚱蜢 来自 http:// ：
VC++是筷子
CBC是汤勺
别人都说用筷子的人聪明，
可用筷子可以喝汤吗？？
。。。。。。
不过也不用担心，
会用筷子的，
能不会用汤勺吗？？
csq_cpu 来自 http://battlenet.yeah.net ：
BCB能用VC的类库，VC能用BCB的类库吗？我不否认VC的强大包罗万象，但BCB思想博大领先，各有各的好处，不必争了，快学才是真
nyra 来自 ：
thanks wenyy!
我很同意你的观点。我上一篇文章主要想谈谈计算机语言，结果，写着写着就把编程环境和编程语言等同了起来，不过我想这也没有什么错，用bcb和vc来说，除了它们用了同样的语法之外，也没有太多共同的东西。
在我看来，要说用软件写程序，好比用积木盖房子，不论你如何变化，总不能离开它原始的设计模型。一个
用于编写程序的软件，就像一堆预现制作好的毛件，你只要组合它就好了。有时也许你有一个很好的想法，本来很简单，但用手边的东西的话，反而费了九牛二虎之力。举例说吧：我想为我的web程序写一个自动生成配置文件的程序。这种东西本来很简单（用bcb这类快速开发工具，当然我最后用的是java，有很多字符处理的工作，用C不合适；win平台又不好用perl。），假如你用vc在mfc的模型下写，my god！我就不说什么了，你可以写一写，试一试。
说了这么多，我还是那个思想，做什么，用什么，什么是合适的，就用什么，没有说最好的，也没有说什么的通吃天下。做为一个程序员，不是只会一种软件就可以的（虽然现在这种思想很普遍）。我想真正的程序员不是能用什么写出什么，而是能用计算机解决问题的人，也就是掌握计算机处理思想的人。
对了wenyy不知你用了托普的M++builder没有？感觉如何？
Fogg Yang 来自 ：
为什么各位在大谈软件的时候不谈一下硬件? 难道几乎是清一色的软件专业人士? 王选教授谈到其成功因素时就提到,同时精通硬件和软件是一个重要因素.(扯远了!)
看一下硬件的发展历程(或者是市场对硬件的最终选择),可以用奥运会的宗旨来描述:更快,更高,更强!
人类对为自己服务的工具的选择:更快,更高,更强!
请大家用发展的眼光看待问题,这不是计算机问题,是哲学问题.
要知道,在任何论坛对VC/VB, BCB/DELPHI, PB, JAVA的褒奖,实际上是在褒奖MICROSOFT,INPRISE,SYBASE和SUN.
JAVA 1/2, C/C++, XML, OR 人类自己的语言,都有不停发展的义务和权利.如果真的要绝对追求效率,C/C++就够了吗? 不知道有没有人比较过用汇编和C编写对VRAM直接写屏的速度(刚好差10%,跟教科书似的,但很重要).
那些完全推崇C/C++的人,如果很自信,完全可以跟裘伯军似的写一个WPS出来,但也没有必要骂VB/PB程序员是傻瓜,因为你在用"低级"的工具,获得了"低级"的效率.同样,VB/PB程序员也不要显耀自己的聪明,因为或许您永远也无法体会到那种PPROFESSIONAL的感觉,只能看着微软新版本的OFFICE,IE,WINDOWS而望洋兴叹了.
"骑着单车,永远也到不了月球." 同样:
"到美国,用不着动用登月火箭."
VC/BC, 都是一个东西: 带有颜色的文本编辑器,只不过文本可以被CPU的EU单元执行.在电脑内部,这些文本从"虚无"
的物质变化为SILICON三级管B-E极间的正向导通压降0.7伏特(1)或截止0伏特(0).
"到底用那一个?"
"你出钱买了哪个,就用哪个"
pophq 来自 http:// ：
vc++我正在用,我觉得人要执著,要盯住一个不放
tiger 来自 http:// ：
这种比较有用吗？面向对象搞了这么多年，如今写程序再也不像过去，为写一个 buttoｎ 什么都得自己来，现在人家把什么都写好了MFC也好，VCL也好，Java Api 也好，无论用熟了那个都能编写出都异常强大的程序。说白了一句话，学习这些东西，无非就是学习类库而已。
至于我自己，比较喜欢Java 其实看看 Microsoft .Net 的类库，大家会很惊讶的发现那个类库于Java Api 何其类似，不说构架，连类名，方法名字都基本一样（第一个字母的大小写不同）由此可见 Java 还是有个很优秀的类库的，不然Microsoft 的拳头产品的framework 与jdk1.2何其相似，C# 与 Java 也何其相似。
莫愁 来自 http:// ：
看了大家的评论,真是各有千秋.我仅从我的经验来发表点看法:
c++ Builder和c++没有可比的，我的办法是两者都学，两者都用。干工作用c++ Builder，得快；自己娱乐用c++，精工出细活。
我认为程序员和诗人一样。如果诗人没有浪漫的清风傲骨，就写不出超凡脱俗的篇章；如果程序员没有浪漫的情结，就只会跟人后面亦步亦趋。
编程应该是一种事业，而不是谋生的工具，不编程序我们一样可以谋生。
lee 来自 http:// ：
各位前辈看完文章后我得利不少，个人认为是vchao 一点
逍遥 来自 http:// ：
谁好谁坏是不能一概而论的
要根据你个人的需求来判断。
好，坏都是有对象性的
vc功能强大，但开发慢,
dephi开发快,
java/j++暂时是浮于较高平台支持之上的.
回复
姓名
邮件地址
主页地址
你的回答
返回 Visual C++/MFC 开发指南在线讨论区
--------------------------------------------------------------------------------
闻怡洋 1999年10月03日成家立页 http://www.vchelp.net(c)版权所有
