管窥Visual C++ 2008 Beta 2
(Orcas
)
Visual Studio 2008 Beta 2(开发代号Orcas)已于2007年7月23日发布,这提供了一个很好的机会让大家对新的C++功能先睹为快,在介绍新功能之前,还是要来先看一看整个Orcas产品的。Orcas的出现,表明了Visual Studio之前较短的18-24个月发布周期的回归,相比Visual Studio 2005发布之前的间隙也短得多。更短的发布周期意味着Orcas之后的,某些需要更多开发时间的产品,目前已经接近完成了,也就是多个媒体已经报道过的“Visual Studio Hawaii”。
对Visual C++而言,Orcas更短的发布周期,导致了MSBuild缺乏相关的支持成了最引人关注之处。以前曾经提过,Visual C++项目能在一个MSBuild任务中完成,但在Visual Studio IDE中,无法选择一个Visual C++项目,使它以MSBuild类型生成。微软C++小组也表明,他们正在做大量的内部工作,以对MSBuild提供支持,看起来似乎只有Hawaii才会集成对MSBuild的支持。还有一种可能,就是对Visual C++ MSBuild的命令行支持,会以某种类似PowerToys的方式提供。
本机代码(Native Code
)特色
Visual C++ Orcas一个明显变化之处,就是已经内建了对Windows Vista用户账户控制(UAC)的支持。在Visual C++ 2005中,与UAC打交道的唯一方式,就是通过创建一个自定义清单文件,并在生成中包含它(在Visual C++项目属性页,清单工具-输入与输出-额外清单文件设置);而在Visual Studio Orcas中,新的属性设置在链接器-清单文件页(Linker | Manifest File),如图1所示,可为Visual C++程序在UAC设置方面,提供更好地粒度控制。
![](https://p-blog.csdn.net/images/p_blog_csdn_net/xieqidong/A%20Quick%20Look%20at%20Visual%20C%20Orcas.gif)
图1:Visual C++ Orcas UAC支持
随着Windows每次新版本的发布,也会有Visual C++新版本的发布,同时,MFC也相应升级对新的Vista界面提供支持。以往每次Visual C++的发布,都会提供一个对Windows通用控件的MFC包装函数,Visual Studio Orcas也不例外,所有用Visual C++ Orcas创建的新工程,默认都遵从Vista的界面方式。同时,MFC控件也设计提供了对非Vista版本Windows的支持,因此,如果在Orcas中为一个对话框添加一个CFileDialog,而最终程序却安装在一台Windows XP电脑上,程序将会显示旧式风格的对话框。
Visual Studio Orcas中缺少了ATL Server——这个产品已经从Visual C++中挪到了一个在CodePlex上共享源代码的项目中。同样的情况也发生在WTL上,微软希望社区中的开发者为它打好代码基础。
除了Vista的界面之外,Visual C++ Orcas还加入了一个新的链接器选项,以生成可利用地址空间随机排列(ASLR)的执行镜像。地址空间随机排列(ASLR)是Windows Vista的一项新功能,它可阻拦黑客试图通过调用位于已知特定地址的某一函数,来利用某些漏洞。当有ASLR功能的镜像加载时,地址空间随机排列(ASLR)会对其随机重新确定基址,这是一种安全技术,在其他的操作系统,如OpenBSD中也出现过。
要利用ASLR,必须生成一个支持随机基地址的镜像,在Windows平台上,Visual C++ Orcas是第一个支持此技术的编译器,且随机化基地址(/DYNAMICBASE为链接器命令行选项)默认状态下是打开的。
互操作性特色
作为跨越本机代码与 .NET鸿沟的桥梁,Orcas中包含了一些新的功能以使互操作性变得更简单就毫不让人意外了。大众期盼已久的、移植到 .NET的STL这次也跟随Orcas一同发布了,且命名为STL/CLR(STL.NET为当时把STL移植到 .NET平台的项目代号)。STL/CLR结合了C++模板与 .NET的泛型概念,这允许C++程序员在STL容器与算法中使用 .NET类型。
Visual C++ Orcas同时也引入了一种新的调度库(Marshaling Library),由此简化了本机类型与 .NET对应类型之间的转换,同时具有高度的可自定义性。尽管大多数C++程序员已经在互操作编程上做了大量卓越的工作,但调度库的引入,提供了一个通用的机制来完成这些转换,且新的语法非常之简单:
#include <msclr/marshal.h>
TCHAR* c_style_string = _T("My C style string");
System::String^ dotNetString = msclr::interop::marshal_as<System::String^>(c_style_string);
C++
与 .NET
Visual C++ Orcas中缺乏的某些高级 .NET功能,如已经包含在C#与Visual Basic.NET中的LINQ,也是一个引人关注之处。C++与C#在托管代码上的分叉,似乎随着未来Visual Studio的发布,也变得越来越大了,原因在于目前微软Visual C++小组集中精力为Windows操作系统提供本机功能支持,同时为适应新的C++语言标准,更新现时的编译器。从某些方面来看,C++在高级托管代码功能支持上的滞后,越来越像Windows SDK与 .NET Framework对新功能支持上的差别。
C++与C#日渐增长的差距,也越来越清晰地表明哪种语言适合于哪种任务:对本机开发来说,最显而易见及唯一的选择当然就是C++了,且对互操作性(interop)工作来说,毫无悬念的赢家也是C++,当然这都要归功于以下三种不同的互操作技术——It Just Works(IJW)、COM Interop及P/Invoke、Orcas中的调度库。
话又说回来,当某个解决方案主要基于托管代码时,选择哪种语言,就有点让人头疼了。C++/CLI是对C++的一个良好扩展,它支持托管代码简单高效的生产率,且 .NET Framework库中所有的功能都可以用在C++上。C++传统上落后的地方,在于可见即所得(WYSIWYG)设计中IDE支持上的滞后——Visual C++ 7(2002)对 .NET设计者不提供任何支持,且Visual C++ 7.1(2003)也只是加入了对Windows Form的支持,而缺少Web Form的支持。ASP.NET 2与C++在编译模式上的不兼容性,导致了用C++来生成一个网站,成了一项艰巨的任务。
在 .NET功能方面,LINQ无疑又加大了C++与C#之间的差距,虽然LINQ很可能在下一次Visual Studio发布时,出现在C++中,但相比C#所支持的全部功能,极有可能仍会有一些版本上的滞后。
从个人角度来看,使用Visual Studio 2005或是现在的Visual Studio Orcas,C#更适用于常规应用程序开发、界面设计及以数据处理为中心的商业程序;C++更适用于系统级编程、或与Windows有着紧密联系的应用程序、及开发填补本机代码与托管世界之间鸿沟的DLL。
结论
Visual C++ Orcas代表了在Visual Studio产品中,Visual C++独特及宝贵价值的复兴——而不是与C#及Visual Basic.NET在托管代码方面,比拼“我也有”的某些功能。Visual C++小组已集中精力于两个领域:与现有代码的互操作性、与Windows操作系统的深度集成,这都是以上其他两种语言的薄弱之处。
我们应该看到,随着Vista而来的一千多个新的本机API,表明了本机代码开发还远远未走到尽头,而Orcas的发布,也充分表明要利用Windows SDK中的头文件,Visual C++的地位牢不可撼。