图 5 显示了带 /clr 开关编译的代码片段。在这段代码中有一个 for 循环，在这个循环中调用本机函数 (GetChar)。在图 6 中，采用 C# 实现相同的代码，并且通过调用 GetChar 来使 CsharpType 类封送处理到 NativeType，如下所示：

class NATIVECODE_API NativeType {
public:
    NativeType();
    int pos;
    int length;
    char *theString;
};

在 C++ 中，用户显式使用本机类型，因此不需要隐式封送。这种类型的优化所节省的成本相当大。在这个示例中，C++ 实现比 C# 实现快 18 倍。

具有 .NET 类型的模板和 STL

Visual C++ 2005 中一些比较有趣的新性能特征是具有托管类型（包括 STL/CLI）的模板、与托管代码的全程序优化、延迟加载和确定性终止。Visual C++ .NET 2003 可以在本机类型上为模板生成 MSIL，但不能在该模板中将托管类型作为参数化类型使用。在 Visual C++ 2005 中，这个问题已经得到纠正，模板现在可以将托管类型或非托管类型作为参数。现在，模板的强大功能可以用于在 .NET 中编写的代码了（您还应该看一下 Blitz++ 和 Boost 库所做的工作）。

C++ 标准模板库 (STL) 是库设计中一个重大革新。它可以让您很好地利用容器和算法而不会牺牲性能，这一点已获证实。在 Visual C++ .NET 2003 中，在模板中对托管类型的限制意味着没有托管类型的配套 STL。Visual C++ 2005 中除了具有这种限制外，还引入了 STL/CLI — 一种已证实可处理托管类型的 STL 版本。.NET 中的基类库 (BCL) 最初在 .NET 中引入了容器，但 Visual C++ 小组中的计划是 STL/CLI 的性能会更加优越。如果您想对 STL/CLI 有更多了解，Visual C++ 开发人员中心中有一篇 Stan Lippman 所撰写的优秀文章 STL.NET Primer。

有了 STL/CLI 后，您可以通过 STL 实现您喜欢的所有内容，包括矢量、列表、双端队列、映射、集合以及哈希映射和集合。您还可以获得排序、搜索、集合运算、内积和卷积等算法。STL/CLI 算法的一个惊人之处是可对本机和 STL/CLI 版本使用相同的实现。STL 的良好设计将通过可移植的强大的代码来让每个 C++ 编程人员受益。

确定性帮助性能

由于您可以使用强大的模式和术语库，编写有效的 C++ 变得轻松许多。其中许多模式和术语（包括 Resource Acquisition Is Initialization (RAII)）使用 C++ 语言中一个称为确定性终止的功能。它的原则是当一个对象被 delete 操作符删除（对于堆栈分配对象）或处于作用域外（对于堆栈分配对象）时，就会调用该对象的析构函数。确定性终止可以挽救性能，因为一个对象占有资源的时间越长（比它真正需要的长），性能下降越多，因为其他对象试图获取相同的资源。

使用 CLR 终止程序会导致终止程序代码在对象处于作用域外（假设释放锁的代码是该终止程序）但还没在对象的终止程序上调用终止线程时在某一个位置执行。显然，这样做并不理想，因为当编程人员期望执行终止线程时，它可能不执行。另外，与对象相关的内存直到终止程序执行后才会回收，这样会使程序对内存的要求增加。

在基于 .NET 的代码中，一个有助于避免这种问题的常见术语是 Dispose 模式。要使用它，开发人员需要为他们的类实现一个 Dispose 方法，然后在不再需要对象时调用该方法。当 C++ 编程人员要对对象调用 delete 时，就可以同时在代码中调用这个方法，但即使在 C++ 中，这样也很容易出错且过于繁杂。诸如 C# 等语言添加了“using”构造，它有助于解决后面两个问题，但对于特殊情况，它也会很复杂且容易出错。

相反，RAII 这个 C++ 术语自动获得和释放资源，而且不容易出错，因为编程人员不需要编写额外代码。Visual C++ .NET 2003 不支持堆栈分配 .NET 对象的确定性终止，但在 Visual C++ 2005 中支持这个功能。

在图 7 的上半部分，可以注意到类型为 Socket_t 的对象使用了基于堆栈的语法，并将具有基于堆栈的清除语义。这样，当在第三行产生一个异常时，会出现什么情况呢？对于基于堆栈的语义，会确定性地为 mainSock 运行析构函数，但由于还没在堆栈中创建 backupSock，所以没有对象可以析构。

要编写语义上等同于 C# 的代码有些困难且容易出错；请参见图 7的下半部分。当然，这个例子很小，但随着这种任务复杂度的增加，出现错误的可能性就会越大。延迟加载

虽然 .NET Framework 为提高性能而进行了微调，但在启动时加载 CLR 还稍微有些延迟。在许多应用程序中，可能有一些代码路径和方案没有托管代码，特别是当通过 .NET 功能对现有的旧式程序进行改造时。在这些情况下，您的应用程序就应该不会有这种相关的启动延迟。您可以使用 Visual C++ 中现有的功能 — DLL 的延迟加载来解决这个问题。

其思想是只在实际需要使用 DLL 中的某些内容时才加载该 DLL。这种思想也可应用于加载内容为 .NET 程序集的 DLL。通过使用链接器选项 /DELAYLOAD:dll（通过它指定想要延迟加载的 .NET 程序集），除了可以延迟加载列出的 .NET 程序集外，还可以延迟加载 CLR（如果所有 .NET 程序集都延迟加载）。结果是，应用程序的启动速度可以完全像本机启动那么快，从而消除了托管应用程序最常见的弊端之一。

为什么 dllexport 不能始终适用

使用 __declspec(dllexport) 有它自己的缺陷。当您有两个映射（DLL 或 exe）都为托管映射，但通过 dllexport 而不是通过 #using 公开功能时，dllexport 的问题就会暴露。因为 dllexport 是一个本机构造，所以每次使用 __declspec(dllexport) 跨 DLL 边界调用时，都会先引发从托管到本机的转换，再引发从本机到托管的转换。这样就难以获得很好的性能。

解决这种性能问题的选择很有限。没有简单的“开关”可以立刻让 __declspec(dllexport) 成为对托管代码没有相关 thunk 的构造。推荐的修复办法是将导出的功能包装在一个托管类型（引用或值类/结构）中，导入程序再通过导出 DLL 上的“#using”访问该类型，从而直接访问导出 DLL 中的功能。通过这种更改，当从托管客户端调用这段托管代码时就不需要进行转换。图 8 中对此做了说明，其中 A 部分显示了与使用 __declspec(dllexport) 相关的成本，B 部分显示了使用 #using 和将函数包装在 .NET 类型中所带来的优化。这种方法的一个潜在问题是导出 DLL 的非托管导入程序不能对 DLL 的功能进行 __declspec(dllimport)。这在进行更改之前应该加以考虑。

图 8 降低 Thunk 成本

图 8 的 A 部分显示了使用 __declspec(dllexport) 将托管函数公开给托管代码的转换路径。在 B 部分中，该函数被包装成托管类型，并使用 #using 来访问该函数。与 A 部分中的过程相比，其结果是省去了成本很高的 thunk。

小结

Visual Studio .NET 2002 引入了带有 Visual C++ 的 .NET Framework 已有很长的时间。C++ 使得编程人员编写高性能托管代码具有很大的灵活性，而且都是按 C++ 编程人员很自然的方式工作的。有许多语言可用于进行 .NET 编程；如果您想获得最大的性能，则 Visual C++ 是显而易见的选择。

Kang Su Gatlin 是 Microsoft Visual C++ 团队的程序经理，他的大部分工作时间都在尝试寻找可让程序运行更快的系统方式。在到 Microsoft 工作之前，他从事高性能和网格计算。