【转帖】备受争议的Visual C++

Visual C++为了让程序员能够自由的使用C++语言完成Windows应用程序的编写，可谓“煞费苦心”，然而，同时因为一些原因Visual C++却饱受争议。这些争议包括以下5点。

1．关于Visual C++对标准C++的支持

前面谈到，Visual C++不是唯一的C++编译器提供者，在linux环境下，GCC就很有知名度。而由于历史原因，Visual C++ 6.0推出的时候，C++的标准还未形成，Visual C++ 6.0对标准C++的支持很差，据上面的数字来说，它只到70%左右。

但是细想，C++的标准化是什么时候？C++自推出以来，其标准只有一个：即1998年由美国国家标准化协会ANSI和国际标准化组织ISO正式发布的C++语言的国际标准C++98（ISO/IEC 14882:1998）。再来看看1998年的Visual C++ 6.0，那时的Visual C++ 6.0已经作为成熟的产品推出，其中包含了一些相对前卫的C++特性。就像要求山顶洞人围猎时必须带有狩猎证一样，我们怎么可以指望Visual C++ 6.0包含对标准C++的完整支持呢？当然，在前面的内容我们也讲到了，Visual C++在后面的版本增强了对标准C++的支持，并使支持率达到98%以上！所以，对那些希望学习标准C++的读者来说，千万不要再抱着Visual C++ 6.0不放了。

提示

关于C++的标准化，2003年10月15日，ISO推出了C++标准的第2版C++2003（ISO/IEC 14882:2003）。该版本在语法特征上没有什么变化，只是纠正了原版的各种错误，并进行了一些技术上的修订。

2．关于Visual C++的体积

在以上几个版本中，Visual C++ 6.0是最小的Visual C++，它的体积大概是一张CD，然而发展到Visual C++ 2008，其体积可以达到2GB！因此很多程序员对于Visual C++的第一印象是太过臃肿，实际上，Visual C++之所以能够这么肥胖，是因为它提供了更多、更强的功能。Visual C++的界面友好性及与其他系统（如：Microsoft Office）的集成性，是谁也不可否认的。在存储空间的成本日益变得廉价的今天，该特性不应成为程序员选择Visual C++的否决因素。

3．关于Visual C++的MFC

MFC是Visual C++的灵魂，至少对其最初的版本来说是这样。然而，MFC让程序员产生了强烈的“MFC依赖症”，一旦离开了MFC，程序员就很难编写出合适的程序，这让Visual C++显得与其他开放技术的不兼容。

MFC将常见的Windows对象和操作都封装起来了，这让程序员感觉到自己是一位面对黑色宇宙的宇航员，一旦离开了宇宙飞船，就会晕菜。至于宇宙飞船为什么可以飞起来，如果一个程序员缺少足够的时间和能力，就很难再去研究。如果一个Visual C++程序员不知道如何使用代码手动的实现一个消息映射，那就很难掌握到真正的MFC。

一言以蔽之，MFC的不幸在于：其高超的封装性反而让程序员望而却步，进而招来更多的负面评价：MFC不好用、MFC是封闭的、Visual C++是可怕的。

微软应该也意识到了这个问题，将所有的程序基于MFC来开发是很可怕的。因此他们提出了ATL，将那些小型的、有用的类扔到ATL里面去，而不必再依赖于MFC环境。比如：当读者编写一个使用CString的程序，就不再需要MFC。如果想将一堆CString扔进一个map当中去，也可以不使用MFC。

4．关于Visual C++的语言扩展

如果你参与过Java语言的开发，你会发现有些事情在Java语言中实现起来轻而易举：

 

该段代码演示了如何获取一个对象的类信息，并从一个类创建一个实例对象。在C++语言中，要实现类似的功能简直比登天还难！但是Visual C++觉得它应该帮助程序员来做这件事，遗憾的是它骨子里还是C++，先天不足，所以最后它不得不依靠一些旁门左道（如：宏）等非正当的手段来维护一个属于自己的王国，而这个王国的基础就是CObject及CRuntimeClass。在Visual C++项目中，很难找到与CObject、CRuntimeClass完全无关的代码，程序员可以通过CObject、CRuntimeClass拥有超强的能力，但是也常常会因为这些黑幕技术感到困惑。

5．关于Visual C++的语法扩展

在Visual C++.NET中，你可以使用如下语句：

 

这段代码被称做托管代码，它采用了C++/CLI（CLI:Common Language Infrastructure）语言（在某段时间，这门语言被称做“托管C++”语言）。“CLI”即公共语言基础结构（Common Language Infrastructure），这是一个支持动态组件编程模型的多层架构。在许多方面，它所表示的对象模型和C++的完全相反。它是一个运行时软件层，一个虚拟执行系统，运行在应用程序和底层操作系统之间。斜线“/”表示它是静态C++对象模型到动态CLI组件对象模型的一种绑定。

C++/CLI语言在兼容原有的C++标准的同时，重新简化了托管代码扩展的语法，提供了更好的代码可读性。和微软.NET的其他语言一样，微软向ECMA提交了C++/CLI的标准化请求，并且被ECMA通过成为正式的标准。C++/CLI现在可以被Visual C++ 2005和更高版本的编译器支持。

大家知道，.NET框架封装了大量的API，例如网络访问、字符串操作、数据访问、XML服务、图形界面控件库、邮件服务、加密服务、文件输入/输出，甚至是WMI管理，也使得应用程序员可以编写更加简洁的代码。通过采用C++/CLI，传统的C++代码可以较快地移植到新的平台上，而且即使不完全重写代码，也可以通过互操作在同一个模块中无缝整合托管和非托管代码，从新的.Net框架中获益。一个比较显著的特性是：使用C++/CLI编写托管代码，内存管理的工作可以让CLR去自动处理，访问时也增加了类型检查，减少了缓冲区溢出和内存泄漏的危险，增加了程序的稳定性。

按理说，这项发明应该值得C++程序员为之欢欣鼓舞，但是，传统的C++程序员对C++/CLI的态度极其复杂。更有甚者，称C++/CLI为“被阉割的C++”。C++/CLI彷徨在标准C++与C#之间，进退两难

摘自《把脉VC++》

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/okaimee/archive/2010/03/26/5418193.aspx