Visual C++应用程序可以识别C/C++并编译，支持MFC类库，并提供了一系列模板，而不是底层的建设上，这就大大加快了程序开发速度和效率，这也是Visual C++一个显著的特点。
然而，Visual C++应用程序终究是面向过程的语言，数据和处理数据的程序是分离的。当对某段程序进行了修改或删除时，整个程序中所有与其相关的部分都要进行相应的修改，从而程序代码的维护比较困难。
为了避免这种情况的发生，在C的基础上中引用了面向对象的设计方法。它是将数据及处理数据的相应函数"封装"到一个类中，而使用类数据变量则称为对象。在一个对象内，只有属于该对象的函数才可以存取该对象的数据。
这样，其他函数就不会无意中破坏它的内容，从而达到保护和隐藏数据的效果。这就是C++。当然，面向对象的C++还支持多重继承、模板、操作符重载、内联函数定义、预处理、宏、全局静态类变量、嵌套类定义等等。
C++太复杂了，任何一个使用C++开发者的企业必将付出更多的成本，因为优秀的C++程序员是少而又少。基于软件企业化的需要，人们很自然地需要一种简单易用、面向对象。
安全灵活的"新一代Windows服务"(Next Generation Windows Services，简写为NGWS)应用程序的语言，于是C#出现了。它全方位简化了C++的功能，使其具有C++所没有的简单易学的优势。它既没有C++"悲剧性"的指针概念，也没有类似"：："、"."和"->"的"愚蠢"操作。
因此我们也可以说，C#才是程序员们所必须掌握的语言。但是，我们不能忽视这一点，语言总归是程序员的工具，谁具有简单易用、支持***技术并能快速有效地进行软件开发，谁就是程序员的工具。
就目前而言，选择C++就意味着选择Visual C++应用程序，而不C++ Builder。这是C++程序员***件让人头痛的事。因为VC与Windows 98/NT同出一炉，相同功能的Visual C++应用程序编译后，其大小要比C++ Builder小得多。不仅如此，其稳定性和完善程序要比C++ Builder要强得多。
但是"Visual C++"这个名字曾误导了很多人，他们认为自己买了一套完全可视的编程系统，类似于Visual Basic，并在刚开始的几天总这样幻想。然而不久，人们认识到他们必须实际编写和阅读C++代码。
虽然Visual C++向导可以节约时间和提高正确性，但程序员必须理解向导所产生的代码，最主要的，还必须理解Microsoft Foundation Class(MFC) Library的结构和Windows操作系统的内部工作方式。
许多C/C++的DOS平台的程序员把这种工作方式评价为"枯燥且艰深晦涩"的过程。尽管新版本的Visual C++6.0提供了控制台应用程序类型，使DOS程序员能方便地进入MFC应用程序的开发，但仍然不能从根本上改变上述弊端。
选择了Visual C++，就必然选择MFC，一种程序结构，一种编程风格。但由于MFC是OWL同时代的产物，已经落后于VCL一个时代了。从开发出基于ATL的WTL可以反衬出MFC的不足。这恐怕是Visual C++程序员最窘的地方。
但我们暂且不提MFC过时的尴尬，单是稍稍地改变一下应用程序的外观，Visual C++应用程序已是力不从心了。例如，想要改变控件的字体和背景，你得重新生成一个类，而VB只需更改一下属性。从Visual C++界面设计的网站的火爆可见一斑。
不仅如此，Visual C++程序员也时常感到另外一种尴尬，一个小小的BMP、JPG图片显示，在Visual Basic中轻而易举的事件，到了VC居然需要那么多的代码，而且在数据库应用程序的开发中还常发生许多一些细微的错误，令程序员们大为恼火。更为甚者，如果有人还想用Visual C++应用程序编写Internet/Intranet程序的话，那简直就是自寻烦恼。
虽然，一个优秀Visual C++应用程序的薪水要比其他程序员高。但是，他所花费的精力不是其他程序员能比拟的，他不仅需要承担高昂的培训费，而且还要承担90%不成功的概率。这恐怕是想成为Visual C++程序员的人最苦恼的事。
当然，我们不是劝你放弃使用Visual C++应用程序，相反还十分支持。因为使用C/C++编写的程序结构和算法能被更多人接受，毕竟C影响了整整20个年头。但是时过今天，我们还能靠它来"谋生"吗？
相信你已经有了自己的答案。当然，我们之所以跳出来，是希望程序员们不单是在这个方面去思考，更主要的是：在我们国家软件发展浪潮到来的今天，我们不能再盲从，我们应该关注软件产业、关注互联网产业、关注信息产业。我们也应该有自己的归宿，难道印度软件大国给我们的启示还不够多吗？
【编辑推荐】
