管窥Visual C++ 2008 Beta 2（Orcas）

管窥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设置方面，提供更好地粒度控制。 图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 TCHAR* c_style_string = _T("My C style string"); System::String^ dotNetString = msclr::interop::marshal_as(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++的地位牢不可撼。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！