C语言和C++有啥区别？

Posted 2023-04-16

一、主体不同

1、C语言：是一门面向过程的、抽象化的通用程序设计语言，广泛应用于底层开发。

2、C++：是C语言的继承，它既可以进行C语言的过程化程序设计，又可以进行以抽象数据类型为特点的基于对象的程序设计。

二、优势不同

1、C语言：能以简易的方式编译、处理低级存储器。C语言是仅产生少量的机器语言以及不需要任何运行环境支持便能运行的高效率程序设计语言。

2、C++：不仅拥有计算机高效运行的实用性特征，同时还致力于提高大规模程序的编程质量与程序设计语言的问题描述能力。

三、特点不同

1、C语言：提供了许多低级处理的功能，但仍然保持着跨平台的特性，以一个标准规格写出的C语言程序可在包括类似嵌入式处理器以及超级计算机等作业平台的许多计算机平台上进行编译。

2、C++：在C++中，类是支持数据封装的工具，对象则是数据封装的实现。C++通过建立用户定义类支持数据封装和数据隐藏。

参考资料来源：百度百科-c语言

参考资料来源：百度百科-C++

参考技术A C和C++的区别：

C是一个结构化语言，它的重点在于算法和数据结构。C程序的设计首要考虑的是如何通过一个过程，对输入（或环境条件）进行运算处理得到输出（或实现过程（事务）控制）。
C++，首要考虑的是如何构造一个对象模型，让这个模型能够契合与之对应的问题域，这样就可以通过获取对象的状态信息得到输出或实现过程（事务）控制。 所以C与C++的最大区别在于它们的用于解决问题的思想方法不一样。之所以说C++比C更先进，是因为“ 设计这个概念已经被融入到C++之中 ”。
下面我们一步一步来分析C++与C的不同：

一、类，类对于初学者，它是一个累赘。类的封装使得初学者对程序产生厌倦，感到不适和麻烦。
二、引用，引用是C++中最好尽量不要用它，除非万不得已。引用对于初学者就更容易产生混淆，不知道哪个是引用，哪个是变量。
三、函数的重载，初学者学函数的重载好像没什么坏处，但是，这会使初学者潜意识里对C语言的变量类型的重要性产生淡化，要记住C语言是对变量类型最敏感了的，变量的类型在C语言里的重要性是不言而喻的。
四、流操作符，和上面同样的道理，使得对变量类型的重要性产生淡化，有时会产生使初学者莫名其妙的结果。
五、操作符重载，典型的高级应用，初学者可能根本用不着，这个东东会让他们觉得C++很难，门槛高，看不懂。
六、继承，以及虚函数，看起来深奥，实用价值很低。还有些东东我就不发表评论了，如：new,delete操作符等
七、误区：以问答形式：
问：C++是面向对象化的而C是面向过程化的？
答：第二对，第一问错，C++并非完全面向对象化，真正的面向对象化的语言恐怕只有Java才算得上。
问：C++能实现C所不能的功能吗？
答：至少我还没有发现
问：学了C再学C++有障碍吗？比如程序设计思想
答：至少我还没有看见谁有此症状。
问：学了C再学C++又要重头开始吗？
答：不，C++下可以实现C语言的一切功能。
问：我学完了C一定还要学C++才能编程吗？
答：完全没必要。
问：C++比C好在哪里？
答：更加符合软件工程学
问：学完了C再学C++是不是很容易？
答：那要看你是不是真正的学完了C语言。

C与C++的最大区别：在于它们的用于解决问题的思想方法不一样。之所以说C++比C更先进，是因为“ 设计这个概念已经被融入到C++之中 ”，而就语言本身而言，在C中更多的是算法的概念。那么是不是C就不重要了，错！算法是程序设计的基础，好的设计如果没有好的算法，一样不行。而且，“C加上好的设计”也能写出非常好的东西。

对语言本身而言，C是C++的子集，那么是什么样的一个子集？从上文可以看出， C实现了C++中过程化控制及其它相关功能，而在C++中的C（我称它为“C+”），相对于原来的C还有所加强，引入了重载、内联函数、异常处理等等玩艺儿，C++更是拓展了面向对象设计的内容，如类、继承、虚函数、模板和包容器类等等。 再提高一点，在C++中，数据封装、类型这些东东已不是什么新鲜事了，需要考虑的是诸如：对象粒度的选择、对象接口的设计和继承、组合与继承的使用等等问题。

所以相对于C，C++包含了更丰富的“设计”的概念，但C是C++的一个自洽子集，也具有强大的功能，同样值得学习 参考技术B 一、最简单地可以这样理解：
C++是C的发展、延续和扩展。除工业特需外，单纯使用C进行实用编程的人已很少。
另外，C#是C++的仿照与扩展（但可能不能算是延继，底层实现完全不同）。

二、最通俗的理解：
1、为了降低编程难度，在C的基础上发展出了C++，C++的大部分语法与C相同，编程环境（编译器）完全不同，低层实现基本相同。
2、为了降低编程难度，在C++的基础上又发展出了C#，C#的大部分语法与C++相同，编程环境完全不同，低层实现的机理也根本不同。
3、在视窗操作系统中，编写实用程序，多数情况下用C++编程比用C编程工作量要减少十倍。
4、在网络应用，特别是三层架构的网站编写方面，多数情况下用C#编程比用C++编程工作量要减少十倍
5、减低了工作量的同时加强了稳定性（编写的代码越少，出错的机率自然越小），不可避免的减低了程序的运行效率（自动生成的代码中，很多是不必要的套路和不必要的调用）。

三、相关知识：
1、1972年美国贝尔实验室的 D.M.Ritchie 在B语言的基础上设计出了计算机C语言，1978年，C语言正式发布并制定语言标准。（够早了吧，比很多玩电脑的人的年龄都大），那时的计算机基本上只有专业的实验室里才能见到，普通人家是不可能有的。
2、1979 年，Bjarne Stroustrup 借鉴 Simula 中 "Class" 的概念，开始研究增强 C 语言，使其支持面向对象的特性，1983 年，这种语言被命名为 C++。此后，C与C++开始相对并行的发展。
3、相对于C语言来说，C++的很多的“高级”的写法和功能，是让编译器的“自动”去替代人工实现，这当然方便了程序编写人员，但是，正如很多自动化的东西一样，它自动生成的代码往往是“通用”的，套路化，在很多情况下，生成的代码的执行效率上会比人工编写的C语言低。这在计算机性能足够的情况下看不出问题，但在一些性能相对较低的运行环境中，就会有非常明显的差别，最典型的就是工业设计中的专用芯片的程序编写中（单片机控制）。
4、从语言的宏观上去看，C语言是面向过程，编程员要思考每一行代码对整个程序运行的影响，它最大的特点就是好的代码前后紧密联系，高速互动，最大的缺点就是出现故障时需要思考分析涉及的范围相对要广。
5、从语言的宏观上去看，C++在C语言的基础上引入了面向对象的概念，也就是说，它在编程思想上引入了一个一个功能模块单元的概念，用它进行程序编写，最重要的一点就是将整个程序的任务先分割成功能单元，单元之间传递必要的数据，每个单元之间相对独立。它最大的特点就是出现故障时，只需要对应功能单元及它的输入输出，这样排除故障就容易和快速得多，程序的运行也会可靠很多。
6、事实上，在当前，对于一般的win下的实用应用的开发，C语言基本上已经无能为力了。因为要在win下实现一个最基本的功能，用C去写，编程者要作的工作相对于用C++所做的工作，可能要多十倍以上。而且也没有足够的资料和可引用的代码（因为这样做的人少，所以，可供借用的也就少）。C++编程在win下已成主流之一。
7、随着计算机性能的发展，及网络技术的发展，C++也有它的后来者，那就是C#，对的，C++后面两个加号，C#的意思就是四个加号。从底层去看，类似于C++对比于C，C#也是方便了编程者但降低了程序的运行效率。
8、C#的运行机理是，基于.net动态库的调用及部分win API的间接调用，C++的运行及win API的调用及部分设备底层的IO调用。C++编译出来的可以是真正的机器二进制代码（也可以是调用C++运行库），而C#编译出来的只是一种中间码在运行中由.net环境进行边解释边运行，所以在计算机性能不足情况下，C#的程序运行速度要明显慢。
9、但也正如C与C++之间一样，C#与C++也在并行发展中，C#能完成的事，理论上C++也能完成，而且可能在效率上会更好。但是，在某些项目上，用C++开发的难度会是用C#开发难度的十倍以上，比如编写一个WEB网站。 参考技术C 【C语言和C++的区别】如下：

1、全新的程序程序思维，C语言是面向过程的，而C＋＋是面向对象的。
2、C语言有标准的函数库，它们松散的，只是把功能相同的函数放在一个头文件中；而C++对于大多数的函数都是有集成的很紧密，特别是C语言中没有的C++中的API是对Window系统的大多数API有机的组合，是一个集体。但你也可能单独调用API。
3、特别是C++中的图形处理，它和语言的图形有很大的区别。C语言中的图形处理函数基本上是不能用在中C++中的。C语言标准中不包括图形处理。
4、C和C++中都有结构的概念，但是在C语言中结构只有成员变量，而没成员方法，而在C++中结构中，它可以有自己的成员变量和成员函数。但是在C语言中结构的成员是公共的，什么想访问它的都可以访问；而在VC++中它没有加限定符的为私有的。
5、C语言可以写很多方面的程序，但是C++可以写得更多更好，C++可以写基于DOSr程序，写DLL，写控件，写系统。
6、C语言对程序的文件的组织是松散的，几乎是全要程序处理；而C++对文件的组织是以工程，各文件分类明确。

想了解更多有关C语言的详情，推荐咨询达内教育。达内教育具有丰厚的师资力量，优秀的教学体系，教学质量突出，实战讲师，经验丰富，理论知识+学习思维+实战操作，打造完整学习闭环。达内教育独创TTS8.0教学系统，并设有企业双选会。达内的OMO教学模式，全新升级，线上线下交互学习，直播学，随时学，随时问，反复学，让学员学习更便捷。感兴趣的话点击此处，免费学习一下 参考技术D 相同的地方：1、语法类似：由于Java可以算是从C++发展而来的，因此Java与C语言的语法比较类似2、编程的熟练程度就是对语言程序库的掌握程度：从某种程度上来说，编程语言都是由语法和相应的程序库所构成，Java有自身的类库，C语言则有标准库。所谓的编程，就是使用与语法来调用和组合程序库中的函数。不同的地方：1、内存管理在Java中，基本不用考虑内存的问题，如果想用一个对象，new一个就可以，这个过程的背后则是JRE为对象分类的一定内存，当JRE发现你不再使用这个对象的时候，他就会自动回收内存，也就是说你只管借东西，不用管归还，因为与有人当你的跟班，在你不使用的时候就把东西归还了，不过这个过程还是有的，只不过是JRE作的而已。但是C则不同，如果你想用，你可以用malloc之类的方法申请内存，当你使用完了，因为没有跟班的，你需要自己把这块内存归还回去，也就是调用free方法来完成这个任务。由于需要显式的归还内存，因此当一个函数需要将一块内存返回给调用者的时候，问题就比较复杂了，不如面向对象和具有内存回收功能的Java那么直观了。对于这个问题，在C语言中，有几种解决方案：(1) 在调用者中先分配好内存，作为参数传入到被调用的函数中(2) 在被调用的函数中分配，使用完后在调用者中释放(3) 在被调用函数中使用static变量，可以将该变量返回2、面向对象Java的面向对象的特点很明显，而C则是一个地道的结构化语言。 Java中有一个字符串类String, 通过调用 String.length()就可以知道字符串的长度，但是在C语言中，则需要调用函数strlen(str)来得到字符串（字符数组）的长度。由于C不是面向对象的语言，也就没有this的概念，因此当使用一个与某个“东西”相关的函数时，就需要不厌其烦的将代表这个“东西”的变量作为参数传递进去。3、名称空间Java通过包（package）来实现名称空间，在C语言中，所有的函数都处于同一名称空间，也就是没有名称空间，因此就会很多程序提供的api接口函数都有一个前缀，例如MYSQL的mysql_init(), mysql_real_connect(), mysql_real_query()等函数名称前面的mysql_。给你找的资料。希望对你有所帮助。。

请问DELPHI和VC有啥区别?除了语言上的.

他们所做的项目方面的优势各是什么?????

VC和Delphi作为开发平台，很重要的一点就是提供了一个"无所不包"的应用框架：VC的MFC和Delphi的VCL。MFC是用C++写的，VCL是用Object Pascal写的。当然，我们都知道，C++的使用范围比Object Pascal广得多，移植性也好得多。这本来是优点，但很有意思的是，正因为如此，微软写MFC时必须考虑最大限度减少对语言本身的改动，而把功夫下在源代码级，以便能尽可能支持ANSI等标准，结果导致MFC的封装复杂而不直观。(尤其是它对消息的封装，下文还会提到)。太多的宏定义和含义模糊且自动生成、不得改动的注释使MFC乃至VC让很多新手望而生畏，不敢"下水"深入学习。而Object Pascal几乎是Inprise"专用"的，不必考虑"标准"问题，因此Inprise写VCL时就把全部精力放在了结构与性能上，结果语言与框架的磨合程度非常好。VCL框架的结构清晰，VCL代码的可读性非常好。许多人说Delphi比较容易上手，也是这个缘故。天下没有白吃的午餐。你要工业标准吗？你要可移植性吗(关于可移植性和兼容性，下文会详细比较)？那么请面对MFC的"天书"级代码吧。

编译和连接：The Need For Speed
不同的语言带来的另一个不同是，编译和连接的速度的不同，以及执行速度的不同。Delphi的编译和连接速度，毫不夸张地说，比VC快几十倍。即使把VC的Incremental Link选项打开，Delphi的编译和连接速度仍比VC快好几倍。并不是说微软的编译器不行，这是由C++的复杂性决定的。模板的处理、预处理和宏的展开都是很费时的。前文不是提到Object Pascal没有模板、预处理和宏吗？这本来是缺点，但带来的一个好处就是编译速度极快。至于编译完的二进制代码，在打开相同的优化选项的情况下，Delphi和VC执行速度并没有太大的差别。
为了克服编译的速度问题，C++编译器一般需要增强的连接器和预处理机制。但是预处理机制仍然存在若干问题：1）程序调试的断点行可能和代码行不同；2）没有将最新的代码信息综合进去；3）容易产生错误的逻辑；4）因为读错文件头而很容易产生类似"Unexpected End of File"的错误。
两个编译器有个共同点是都能识别无用的"死"代码，比如一个没有用的函数等等。编译后的程序将不包含这些多余的信息。Delphi在这方面作得更加出色。它可以让你在编辑器中可视化地提示出那行代码是"活"的、那行代码是"死"的。这样你就能整理出最精简的代码。Delphi在编译后将在左边显示一个小蓝点表示这行代码是"活"的。Visual C++做不到这点。
Delphi编译后可执行文件至少有200K（如果不使用VCL，仅仅使用WinAPI，文件的大小将大大缩小）但是Visual C++编程使用MFC编译后的可执行文件通常只有几十K，主要是因为微软已经将系统运行库包含在Windows系统了（Borland公司曾经和微软协商这个接口，但是微软利用操作系统的优势不愿意公开）。同样道理，使用BDE开发的的数据库程序必须附带3-5M的额外系统文件，也是非常不协调的。
非常有趣的是，Delphi能够使用由C++ Builder创建的的OBJ文件，但是使用上受很大的局限性。
最后，Visual C++的编译和连接时的错误信息比Delphi要详细和具体的多。特别是使用ATL开发更加如此。

应用框架：MFC？有KFC流行吗？
应用程序框架(Application Frame)，有时也称为对象框架。Visual C++采用的框架是MFC。MFC不仅仅是人们通常理解的一个类库(同样，Delphi的VCL也不仅仅是一个控件库，尽管它的名字叫"可视控件库")。你如果选择了MFC，也就选择了一种程序结构，一种编程风格。MFC早在Windows 3.x的时代就出现了，那时的Visual C++还是16位的。经过这些年的不断补充和完善，MFC已经十分成熟。但由于原型出现得比较早，MFC相比于VCL落后了一个时代。尽管微软对MFC的更新没有停止，我也经常读到"只要Windows不过时，MFC就不会过时"之类观点的文章，但就象Inprise(原Borland)的OWL框架的淡出一样，MFC的淡出也是早晚的事。其实MFC是和OWL同一个时代的产物。OWL已经不在了，MFC怎能不"居安思危"呢？如果MFC青春永驻，微软的开发人员也不会"私自"开发出基于ATL的WTL呀。当然，WTL的地位不能和MFC比，它并不是微软官方支持的框架，封装的功能也相当有限。但至少也反衬出了MFC存在的不足。
我们以为，最能体现一个应用程序框架的先进性的是它的委托模型，即对Windows消息的封装机制。对Windows API的封装就不用说了吧。大同小异，也没什么技术含量。如果高兴，你也可以自己写一个类库来封装。但对Windows消息驱动机制的封装就不是那么容易的了。最自然的封装方式是采用虚成员函数。如果要响应某个消息就重载相应的虚函数。但出乎我的意料，MFC采用的是"古老"的宏定义方法。用宏定义方法的好处是省去了虚函数VTable的系统开销(由于Windows的消息种类很多，开销不算太小)。不过带来的缺点就是映射不太直观。对于MFC，则是"太不直观"了。它的消息映射代码虽然是可见的，但"劝君莫碰"。好在VC的ClassWizard可以自动生成消息映射代码，使用起来还算方便。但和VCL的委托模型相比，MFC的映射方法就显得太落后了。而Delphi的Object Pascal因为没有"标准负担"，语言引入了组件、事件处理、属性等新特性。由于功夫做在编译器级，生成的源代码就显得十分简洁。似乎VC是"让框架迁就语言"，而Delphi是"让语言迁就框架"。
我想举一个对字符串操作的封装的例子来说明MFC和VCL的优缺点。在MFC中，CStringList类有加入、获取、删除等功能，但VCL的TStringList类除了上述功能还有排序、从逗号分隔的字串读入、流输入输出等功能。但同样的字符串替换功能，VCL的StringReplace要比MFC的CString::Replace慢2－3倍。总的来说，VCL的封装比MFC更为高层，更为抽象，但不可避免地带来的问题是某些部分执行效率比MFC略低。这就象低级语言(如汇编)的执行效率比高级语言(如Basic)高，但编程效率较低。鱼和熊掌不可兼得嘛。
VCL比之MFC的另一优点是对异常处理的支持，而一大缺点是对多线程支持差。VCL的大部分都不是针对多线程优化的。虽说VCL提供了简化多线程操作的类，但只是工作者线程(worker threads)使用起来比较简单。如果线程要和界面打交道的话事情就变得麻烦了，因为除了应用程序的主线程，任何线程不能访问任何可视的VCL部件。你不得不使用Synchronize方法等待主线程处理它的消息，然后在主线程中访问VCL部件。而MFC就没有这样的限制。

稳定性与完善程度：VC是老大哥
VC要比Delphi稳定和完善。VC的发展历史比Delphi长，微软的总体实力比Inprise强。VC的框架MFC经历了那么多年的发展和完善，功能非常全面，而且十分稳定，bug很少。其中你可能遇到的bug也更少。而且有第三方的专门工具帮助你避开这些bug。如此规模的一个类库，能做到这一点不容易。不要小看了这一点，很多专业程序员就是为这个选择VC的。因为尽管VCL比MFC的抽象程度高，封装较为高层，但由此带来的开发效率的提高对高手来说毕竟是有限的。而如果你遇到一个怪问题，调试了半天，发现不是你的代码有错，而是VCL的bug，你作何感想？虽说遇到这类问题的可能性很小，但对VCL的形象的影响可不小。Delphi的IDE太占资源，启动速度太慢，和某些显卡驱动程序冲突，VCL中有bug，调试器不够健壮，对不稳定的第三方控件没有防护措施 …… 问题多多，在这方面Delphi不如VC。希望Inprise能更上一层楼。顺便说一下，我们在网上看到有些人极言Delphi的不稳定，说几分钟出现20多次非法操作。Delphi的确不如Visual C++稳定，但也不至于如此呀。我估计是那位朋友的Delphi装了某些有问题的第三方控件，导致了Delphi的频频出错。不妨卸下那些控件试试？

可移植性：立足现实，放眼未来
Inprise正在开发Delphi的Linux版本，代号为Kylix。也许通过Kylix，用VCL构架编写的Windows程序向Linux移植成为可能。但这只是可能。因为在目前Inprise的兼容性工作做得并不好。低版本的Delphi不能使用高版本的VCL组件，而高版本的Delphi竟然不能使用低版本的VCL组件。真是岂有此理，我们很少看见软件有不向下二进制兼容的。如果Windows 98不能运行95的程序，Windows 95不能运行3.x的程序，Win 3.x不能运行DOS程序，你还会用Windows吗？如果Windows 95的程序必须经过重新编译才能在98下运行，98会卖得那么好吗？"同门兄弟"C++Builder和Delphi也不能互相使用对方的组件，甚至同一套VCL库的文件名也不一样。所以一个组件有for D1/D2/D3/D4/D5/C1/C3/C4/C5这些不同版本是常有的事，而且随着Delphi和C++Builder版本的升级可能还会增加。希望Inprise能先解决同门兄弟的兼容性问题。而微软的VC就没有这类问题。MFC1.0的程序也可以毫无障碍地在VC6.0下编译通过。

集成界面：宏观与微观
就大处说，VC的集成界面是不如Delphi的。Delphi仅仅一个Object Inspector就可以将VC的一堆Wizards比下去，何况它还有Code Explorer、ToDo List等。但从小处，又可以看出Delphi的不成熟。比如"自动完成"功能的智能化程度和提示详细程度不如VC，响应速度也没有VC快。
Visual C++所带的MSDN是一部"开发者的百科全书"，信息庞大，查询方便，这方面比Delphi更专业。很多帮助项都有源程序示范。
Delphi的OpenTools是完全面向第三方的开放系统，开发者可以修改很多Borland公司自身的功能，从IDE的可扩充性上说Delphi更好。

调试：细微之处见真功
Visual C++和Delphi的调试功能都非常强大，同时都具有单步可视化调试、断点跟踪、运行时改变变量、鼠标指向可以得到变量值等等功能。对DLL的输入输出也能方便的管理，能够进行源码级别的调试。
相对而言，Visual C++能够更加方便地看到变量的变化情况，这包括对结构可以展开成数据树，从而了解每一个变量的值，每一步调试，变化了的变量会加红，从而使调试更加方便。另外，Visual C++的块内存察看比Delphi也要方便。
当然，Delphi也有很多体贴的细微之处，比如在线程调试的时候，Delphi能够很方便地察看线程的变化，Visual C++却必须要弹出一个模式对话框。

数据库开发：Delphi一枝独秀
数据库支持是Delphi的强项。这主要体现在Delphi与BDE的无缝集成，以及Delphi提供的那一大堆现成的数据库操作控件。这是VC望尘莫及的。目前Delphi支持BDE、ADO、InterBase三种数据库访问方式。所有的方式都能拖拉到应用程序中实现可视化操作。正是因为Delphi对数据库类的包装，使得用户操作数据库不像在Visual C++中必须从开始到最后都要干预。明显地提高了开发速度。
Delphi中使用WebBroker控件还能很方便地构造出基于数据库的Web页面，通过HTML管理Web数据库。 Visual C++访问数据主要通过ADO和OLEDB，很多ActiveX控件也能添加数据库功能。但是没有像Paradox这样的桌面数据库，Access相对功能太弱了。也许SQL Server是不错的选择。

COM：新技术的力量
COM是组件对象模型的缩写。它是OLE和ActiveX技术的基础，COM定义了一组API和一个二进制标准，让不同的编程语言、不同平台的彼此独立的对象相互进行通讯。
COM是Microsoft制订的行业标准。但Delphi也为COM提供了强大的语言支持。支持接口、variant、宽字符串功能。这些对COM的封装确实比C++更方便。比如在C++（没有类框架）进行COM编程时，变体定义为oaidl.h文件中的VARIANT结构。要处理变体，必须手工调整oleaut32.dll中VariantXXXX() API函数对其进行初始化和管理，如VariantInit()、VariantCopy()、VariantClear()等等。
Visual C++实现COM编程有一种特殊的方法就是使用ATL。ATL使用Visual C++特有的多重继承来实现COM接口。虽然不见得实现COM服务和控制更容易，但是ATL和最新COM技术的接口，基于模板的构造都比Delphi强。ATL更有利于建立小巧、快捷的COM组件程序。
按目前通用的观点，Visual C++应用到COM服务程序更有优势，Delphi应用到COM组件程序更合适。

昨天，今天，明天
技术的进步在很多时候是此消彼长的。当初Borland的Turbo C和Borland C++几乎是C/C++程序员唯一的选择。微软的Quick C(现在还有人知道这个产品吗？)和Microsoft C/C++从来也没有成为过主流。但Borland C++又流行了多少年呢？不久就被新崛起的Microsoft Visual C/C++压下去了。于是Inprise(原Borland)拣起了当年Turbo Pascal和Borland Pascal的辉煌(事实上Borland的成名作就是第一个Pascal编译器)，全力推出了Delphi。Delphi当初推出时被称为VB杀手，但VB现在仍然活得挺好。毕竟微软是靠Basic起家的嘛，VB不是那么容易被打败的。Inprise想了想不和VB争了，使用Delphi的IDE和VCL配上C++语言，推出了C++Builder，又向Visual C++的市场发起了夹攻。C++Builder似乎是个不错的折衷选择了？再仔细想想！C++Builder的优点Delphi都有，但Delphi的优点C++Builder未必有。比如C++Builder的编译速度比VC还慢，哪能和Delphi比？而且因为VCL是Object Pascal写的，C++语言和VCL磨合得并不好。C++Builder的bug比Delphi还多，甚至Sample代码中还有错。VCL的部分功能不能使用，要靠嵌入pascal代码访问。C++Builder可用的第三方控件远没有Delphi多。
唉，真是金无足赤。Microsoft和Inprise，谁会笑在最后呢？

鱼和熊掌：艰难的选择
选择一个开发工具依赖于很多不同的因素，每个人都能因为某种语言的某个缺陷而放弃学习或使用这种语言。任何程序员都希望自己喜欢的工具能达到理想的境界，通过上面不完善的比较，我想大家都有自己的看法。我们认为影响大家选择开发语言的因素主要包括：
1） 哪门语言更容易入门？
学习一种语言需要投入大量的时间和精力。开发程序的开发成本是值得考虑的现实。一个熟练的Delphi程序员和一个熟练的VC程序员工作效率是一样的。但是，成为熟练的程序员必须很快掌握一门语言的技巧。不幸的是，目前熟练的Visual C++程序员是十里挑一。相对而言，Delphi更适合初学者。
2） 哪门语言有更多可继承的代码？
语言代码的可重用性是加快开发效率明显方面，从早期的过程、函数到现在的组件技术都是朝这个目标在奋斗。这两种语言对代码重用的理解是不一样的，Delphi主要通过VCL控件来实现代码重用，Visual C++实现起来就比较复杂。
3） 语言自身的本性。
就技术(主要指应用框架)来说，Delphi目前领先于Visual C++。但稳定性和健壮性的不足又让我对Inprise"想说爱你不容易"。而VC尽管发展到今日已十分完善，但MFC框架已是明日黄花了。如果不使用MFC，目前又没有合适的替代品。根据你的需要和实际情况做选择吧。实际上Visual C++和Delphi也不是简单竞争关系。它们在许多领域并不重叠，甚至是互补的。到底怎样取舍，要根据你的项目特性决定。如果你开发系统底层的东西，需要极好的兼容性和稳定性，选Visual C++吧。你可以只调用Windows的各种API，不用MFC。如果你写传统的Windows桌面应用程序，Visual C++的MFC框架是"正统"的选择；如果界面部分占这个应用程序代码比例较大的话，或者Delphi中有相关功能的控件的话，Delphi是事半功倍的选择。如果你为企业开发数据库、信息管理系统等高层应用("高层"是相对于"低层/底层"而言的，不是说技术高级或低级)，而且有比较紧的期限限制，选Delphi比较好。如果你熟悉的语言是Object Pascal，又不打算学复杂的C++，那么Delphi几乎是唯一的选择。传统的观点是：Delphi适合编写Internet/Intranet、表格制图、数据库操作、高级用户界面等等。Visual C++适合编写设备驱动、COM服务程序、科学计算、控制台（console）程序、WinCE的应用和一些小的工具等等。应用范围的不同要求好的程序员同时精通这两门语言。
4） 语言的前景和可扩充性。
Delphi是Inprise的旗舰产品之一，前景应当还是比较乐观的，而且Inprise已经在向Linux进军了，而微软还迟迟没有动作。遗憾的是，Inprise公司Delphi的创始人已经跳槽到微软去主持Visual J++和C#项目了。但愿对Inprise冲击不会太大。
微软的Visual C++的前景又怎样呢？Visual Studio 7.0就要推出了。这一版本将加强网络开发的特性。看来微软虽然被判解体，开发实力可是一点没打折扣。
另外，虽说MFC已稍显落后，但不是说它不值得学。事实上，不学MFC就等于没学VC。利用MFC框架开发程序仍然是目前开发桌面应用的主流模式，而且还会保持相当长的时间。微软公司CEO史蒂夫·巴尔默(Steve Ballmer)曾说，.NET流行还得等2－3年。那么，MFC至少还有2－3年的生命空间。在技术日新月异的IT界，2－3年实在是很长一段时间了。好好把握吧。即使你不使用MFC框架，花点时间看一下MFC的封装机制对你熟悉C++的OOP机制和Windows底层功能也是很有好处的。而VCL的源代码是Object Pascal的，对C/C++程序员就没有这个"额外"的作用了。

参考资料：http://blog.sina.com.cn/u/53786359010004b8

参考技术A 语言不同，任何地方都不同，维有相同的是它们都是开发工具。