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

5.关于Visual C++的语法扩展
在Visual C++.NET中,你可以使用如下语句:
白乔原创:备受争议的Visual C++_MFC_02 
这段代码被称做托管代码,它采用了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去自动处理,访问时也增加了类型检查,减少了缓冲区溢出和内存泄漏的危险,增加了程序的稳定性。

===========================================
白乔原创:备受争议的Visual C++_C++_03
以上摘自《把脉VC++》第2.1.4小节的内容