互操作性特色

作为跨越本机代码与 .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++的地位牢不可撼。