优化增强您的Visual C＋＋应用程序

　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 工作之前，他从事高性能和网格计算。

查看本文来源