作为一个尼康“玉米”，你是否知道尼康单反镜头上的VR、AF-S是什么意思。而作为佳能的“粉丝”你是否又知道标有USM/U、UD标识的镜头好在那里呢？如果你对这些不是很清楚的话，请往下看。

镜头标识的含义（尼康篇）

AI：Automatic Indexing自动最大光圈传递技术
　　发布于1977年，是Nikon F卡口的第一次大变动。AI是指将镜头的最大光圈值传递给测光系统以便进行正常曝光测量的过程和方法。当一个AI镜头被装在兼容AI技术的机身上时，该镜头的最大光圈值在机械连动拨杆的自动接合和驱动下传递给机身的测光系统，以实现全开光圈测光。Nikon F2A、F2AS、Nikkormat EL2、FT3和FM是第一批获益于这项技术的机身。
代表镜头：Nikkor AI 50/1.4

AI-S：Automatic Indexing Shutter 自动快门指数传递技术
　　在1981年，Nikon对全线AI镜头卡口进行了修改，以便使它能够与即将投入使用的FA高速程序曝光方式完全兼容，这些修改后的新镜头就是AI-S卡口Nikkor镜头。根据镜头光圈环和光圈直读环上的橙色最小光圈数字以及插刀卡口上的打磨凹槽，非常容易识别。当AI-S镜头用于Nikon FA机身时，它能够根据自身的焦距向机身提供信息以选择正常程序或高速程序，在快门速度优先自动曝光方式时，它们能够在非常宽的光照范围内提供一致的曝光控制。(因为AI-S镜头是为FA上的曝光“自动化”而定制的，因此机身的自动曝光连动拨杆能够非常流畅地控制AI-S镜头的光圈，以达到更为快速而精确的曝光控制)。
代表镜头：Nikkor AIS 50/1.4

AF-S: Silent Wave Motor 静音马达
　　代表该镜头的装载了静音马达(Silent Wave Motor，S)，这种马达等同于佳能的超音波马达(ultrasonic motor)，可以由“行波”(travelling waves)提供能量进行光学聚焦，可高精确和宁静地快速聚焦，可全时手动对焦。 可支持AF-S 镜头自动对焦的相机有 F5 ； F4； F100； F90X； F90； F80； F70； F65； D1； D1X； D1H； D100，其余的机身可以接用，也可以测光，但不能自动对焦。
代表镜头：28-70mm f/2.8 ED-IF AF-S Zoom-Nikkor

D型镜头：Distance 焦点距离数据传递技术
　　代表镜头可回传对焦距离信息,作为 3D(景物的亮度，景物对比度，景物的距离)矩阵测光的参考以及 TTL 均衡闪光的控制。1992年推出。
代表镜头：28-105mm f/3.5-4.5D AF Zoom-Nikkor

CRC：Close Range Correction 近摄校正
　　采用浮动镜片设计，保证近摄时光学素质不下降，例如AIS 24/2.8、AF 85/1.4D IF之类均采用了CRC技术。

DC : Defocus-image Control 散焦影像控制
　　尼康公司独创的镜头，可提供与众不同的散焦影像控制功能。镜头的前端有一个散焦定位转环，该环上的光圈值从F2到F5.6共4挡，分别标在环的左右，用R（后景散焦）与F（前景散焦）来指示。这是一种特殊的定焦镜头，其最大特点在于容许对特定被摄体的背景或前景进行模糊控制，以便求得最佳的焦外成像，这一点在拍摄人像时非常有价值，它还可以帮助我们根据所想要表现的来控制照片的各个部分，这也是其它厂家同类镜头所无法比拟的。
目前尼康只有2支DC镜头：AF DC 105mm f/2D、AF DC 135mm f/2D

ED : Extra-low Dispersion超底色散镜片
　　是指这支镜头内含 ED 镜片，最大限度降低镜头色差（chromatic aberration），从而保证镜头有优异的光学表现。
代表镜头：80-200mm f/2.8D ED AF Zoom-Nikkor

G型镜头
　　与D型镜头不同的是，该种镜头无光圈环设计，光圈调整必须由机身来完成，同时支持3D矩阵测光。这样的设计减轻了镜头重量，降低了生产成本。该种镜头与F5、F100、F80、F65、F60、F55、F50、F401、PRONEA和D1机身完全兼容，对于F4、F90\F90X、F70、F801和F-601等机身，只能使用程序曝光和快门优先曝光模式。与剩下的其他机身不兼容。G型Nikkor镜头操作更为简便，理论上没有误操作，因为它无需手动设置最小光圈。这是塑料AF镜头的延续，针对那些几乎从不手动设置镜头的摄影者。现在Nikon有将G型头推广的趋势。
代表镜头：28-80mm f/3.3-5.6G AF Zoom-Nikkor

IF : Internal Focusing内对焦技术
　　所谓内对焦是指镜头在对焦时，前后组镜片都不移动，而由镜头内部的一个对焦镜片组（focus lens group）的浮动来完成对焦，对焦时镜头长度保持不变。IF技术的采用使快速而安静的对焦变为可能。
代表镜头：85mm f/1.4D IF AF Nikkor

IX镜头
　　1996年Nikon为APS相机Pronea发布的价廉、紧凑的镜头。性状与塑料AF-D镜头相同。不能适配于非APS机身。减少了预留给反光镜的空间，意味着这类镜头不同用于35mm相机，而且像场也太小，不足以覆盖35mm胶片。但是标准的AF镜头却可以用于APS相机。

Micro
　　是指这只镜头是微距镜头，或有微距拍摄的功能
代表镜头：105mm f/2.8D AF Micro-Nikkor

N：New 新型
　　Nikon一些改进型镜头的标志，例如著名的AF 80-200/2.8D ED(N)

N/A：全时手动对焦
　　与佳能的FTM一样。

P型镜头：内置CPU镜头
　　机身内置聚焦马达是个“以不变应万变”的策略，但这个策略对巨大的望远自动镜头并不能很灵，这使得Nikon新机身无法高效使用望远镜头。1998年Nikon发布了内置了CPU手动聚焦长焦镜头(P)，以满足AF机身先进的自动曝光功能，从而部分地解决了这个问题。尽管P型镜头看起来和AI-S镜头是一样的，但这些镜头却拥有AF镜头的电子和大部分性能。
目前只有3支P型镜头：500/4 IF-ED、1200-1700/5.6-8 IF-ED和45/2.8。

PC - Shift：移轴镜头

　　移动镜头光轴调整透视的镜头。多用于建筑摄影。

RF : Rear Focusing 后组对焦技术
　　与IF不同的是，RF镜头由后组镜片（rear lens groups）完成对焦。由于后组镜片比前组镜片要小，易于驱动，所以保证了迅捷的对焦速度，而且镜头长度一样不变。RF对改善成像质量亦有贡献。
代表镜头：85mm f/1.8D AF Nikkor

S：Slim 轻薄
　　Nikon一些薄型镜头的标志，例如AIS 50/1.8S。

SIC：Super Intergrated Coating 超级复合镀膜

TC：Teleconvertor 增距镜

VR: Vibration Reduction 电子减震系统
　　NIKON防手震镜头的代号，可用于手持摄影在低速快门时，增加画面的稳定性。能支持VR的机身有 F5、F100、F80、F65、D1、D100。其余机身可以使用镜头但不支持VR功能。
代表镜头：80-400mm f/4.5-5.6D ED VR AF Zoom-Nikkor

镜头标识的含义（佳能篇）

AFD：Arc-Form Drive 弧形马达
　　为早期EF镜头的AF驱动而开发的弧形直流马达。与USM马达不同，AFD马达对焦是有声的。

DO：Multi- Layer Diffractive Optical Element 多层衍射光学元件
　　Canon于2000年9月4日宣布研制成功世界上第一片用于照相机摄影镜头中的“多层衍射光学元件”。多层衍射光学镜片同时具有萤石和非球面镜片的特性，所以该镜片的推出，是光学工业的一个里程碑。衍射光学元件最重要的特性是波长合成结像的位置与折射光学元件的位置是反向的。在同一个光学系统中，将一片MLDOE与一片折射光学元件组合在一起，就能比萤石元件更有效地校正色散（色彩扩散）。而且，通过调整衍射光栅的节距（间隙），衍射光学元件可以具有与研磨及抛光的非球面镜片同样的光学特性，有效地校正球面以及其他像差。
代表镜头：EF 400/4 DO IS USM

EF: Electronic Focus 电子对焦
　　佳能EOS相机的卡口名称，也是EOS原厂镜头的系列名称。

EMD：Electronic-Magnetic Diaphragm 电磁光圈
　　所有EF镜头的电磁驱动光圈控制元件，是变形步进马达和光圈叶片的一体化组件，用数字信号控制，灵敏度和精确度都很高。

FL：Fluorite 莹石
　　一种氟化钙晶体，具有极低的色散，其控制色差的能力比UD镜片还要好。从严格的意义上来说，莹石不是玻璃，而是一种晶体。它的折射率很低（1.4）而且不受潮湿影响。莹石镜片一般不会暴露在外，所以你不大会直接接触到。莹石镜片不如普通玻璃耐冲击，但也不像想象中的那么易碎，所以在使用中并不需要特殊的照顾。

FTM：Full-time Manual Focusing 全时手动对焦
　　即无论什么时候，即使是镜头正在自动对焦时，都能用手动调节对焦，不会损坏镜头。

L: Luxury 豪华
　　佳能专业镜头的标志。和消费级镜头相比，L头带有研磨非球面镜片、UD（低色散）、SUD（超低色散）或者Fluorite（萤石）镜片，这些是镜头出色的光学质量的重要基础。通常镜头的构造质量也要优秀很多。其标志为镜头前端的红色标线，是佳能的高档专业镜头。
代表镜头：EF70-200/2.8 LU

IS：Image Stabilizer 影像稳定器
　　影像稳定器是通过修正光学部件的运动减小手颤动对成像的影响，所以也称防手震镜头。在IS镜头中，装有一个陀螺传感器，它能检测手的振动并把它转化为电信号，这个信号经过镜头内置的计算机处理，控制一组修正光学部件作与胶片平面平行的移动，抵消手颤动引起的成像光线偏移。这个系统能够有效地改善手持拍摄的效果，对一般情况而言，IS镜头允许您使用比理论上低两级的快门速度。也就是说，您用普通300毫米镜头时，只能选择1/250秒以上的速度，而使用300毫米IS镜头就可以用1/60秒拍出清晰的照片。
代表镜头：EF28-135/3.5-5.6 U IS

MM：Micro-Motor 微型马达
　　这是传统的带传动轴的马达。比较费电。不支持全时手动(FTM)。多用于廉价的低档次镜头。

SF：Soft Focus 柔焦镜头
　　用这种镜头拍摄出来的照片与相机移动或调焦不实的效果大不相同，它利用刻意设计的球面像差，而使被摄景物既焦点清晰又柔和漂亮。柔焦的效果视光圈大小及专门的调节装置而有强弱之分。
代表镜头：EF135/2.8SF

S-UD：Super Ultra-low Dispersion 高性能超低色散镜片
　　一片S-UD大体与用一片萤石镜片的效果相近。

TS：Tilt Shift 移轴镜头
　　移动镜头光轴调整透视的镜头。移轴镜头的作用，除了纠正透视变形，还能调整焦平面位置。正常情况下，相机焦平面与胶片平面平行，用大光圈拍摄，焦平面的景物清晰，焦外模糊；若用移轴镜头调整焦平面，能改变清晰点。 显然，移轴镜头最合适建筑、风景和商业摄影。 EF移轴镜头不设AF功能。
佳能的TS镜头目前有TS-E24/3.5L、TS-E45/2.8和TS-E90/2.8三款。

UD: Ultra-low Dispersion 超低色散镜片
　　一种特殊类型的光学玻璃，由于能够控制光谱中光线的色散现象，被广泛用于镜头的色差控制。两片UD一起用大体与用一片萤石镜片的效果相近。

USM/U：Ultrasonic Motor 超声波马达
　　大部分EF镜头使用的对焦马达类型，利用频率在超声波区域的振动源转动的马达，是实现宁静、高速AF的主要部件。EF镜头的超声波马达有两种，环形超声波马达（Ring-USM）、微型超声波马达（Micro-USM）。采用超声波马达的镜头在前端有一黄色环，标记着”ULTRASONIC”。环形超声波马达是佳能中高级USM镜头使用的对焦马达，其驱动组件是环形的，在驱动时不需要使用任何齿轮之类的传动件。因扭矩很大，所以启动和制动的速度比一般的对焦马达快很多。全时手动只能在环形超声波马达头中实现，要注意如EF 200/1.8L、EF 500/4.5L和EF 600/4L、EF 50/1.0L、EF 85/1.2L等不能实现全时手动。微型超声波马达是一种小型圆柱状超声波马达，在速度和安静程度上不如环形超声波马达，而且不能全时手动对焦，但因其较低的制造成本，所以较多用在中低档的EF镜头上。
代表镜头：EF24-85/3.5-4.5U

背景

当 Microsoft 发布第一版的 Visual C++ 编译器时，其主要作用是支持 MFC 框架。对于所有实际应用来说，Visual C++ 和 MFC 被看作是一种产品。多年来，MFC 和 Visual C++ 编译器都已经成熟。同时，Visual C++ 编译器已经成为拥有其自己权利的产品，不必依赖于 MFC 并支持其他技术，如活动模板库 (ATL)、标准模板库 (STL)，以及其他多种技术。现在，MFC 只是 Visual C++ 编译器支持的多种库的一种。因此，现在使用不带 MFC 的 Visual C++ 开发项目的情况是非常普遍的。

我是在发现运算符 new 失败后，我的 STL 代码会出现异常行为时才开始撰写这篇文章的。令我惊讶的是，我发现运算符 new 失败时，Visual C++ 6.0（以及支持 STL 的所有以前版本）与 STL 不兼容。我正在进行的项目没使用 MFC，所以我的观察仅基于非 MFC 代码的情况。当我开始研究基于 MFC 的示例时，我发现 MFC 定义了运算符 new 的很多不同行为。钻研本篇文章之前，我想小结一下内存分配失败时运算符 new 的行为。为了更好地进行比较，我将讲述 Visual C++ .NET 下的行为，因为它与以前的版本不同。

C++ 标准声明运算符 new 在失败时应引发异常。具体地说，引发的异常应该是 std::bad alloc。这是标准行为，但 Visual C++ 6.0 中的行为取决于您如何使用它以及使用什么样的版本。图 1 显示了内存分配失败时运算符 new 的 Visual C++ 行为。

可以看到，只有 Visual C++ .NET 中的非 MFC 代码才遵循该标准。如果您使用 MFC，那么 new 将引发一个异常，但其类型不正确。如果您使用的 STL 的实现包含 catch (std::bad alloc) 语句，用该语句来处理内存失败的情况，那么起作用的即装即用的唯一组合方式就是无 MFC 的 Visual C++ .NET。Visual C++ 6.0 随附的 STL 实现使用 catch(...) 来处理运算符 new 失败，因此如果您使用 MFC，当运算符 new 失败时，Visual C++ 6.0 随附的 STL 实现将正确操作。

假定 MFC 提供的运算符 new 实现引发异常 (CMemoryException)，并且在 Visual C++ .NET 中非 MFC 的运算符 new 也引发异常 (std::bad::alloc)，那么我认为在所有实际应用中，这些情况将不会产生问题。那么，在基于 Visual C++ 6.0 的项目中不使用 MFC 而使用 STL，这种常见方案又会怎样？这是本文剩余部分将讨论的重点。

运算符 New 返回 NULL

回到本文开始部分的问题，一般来说，不检查运算符 new 返回的指针值是否为 NULL 有两个原因，其一为：运算符 new 从来就不会失败，或者运算符 new 会引发异常。

即使您认为运算符 new 从来就不会失败，不检查其返回值仍不是良好的编码习惯。虽然桌面应用程序很少会遇到内存不足的情况，但是用户在其 100MB 的 Excel 电子表格上按下 F9 时，仍可能导致应用程序内存不足。对于希望每天 24 小时都在运行和处理数据的基于服务器的应用程序而言，特别是在共享的应用程序服务器上的应用程序，内存不足的情况是非常可能发生的。如果不能保证应用程序在一段时间内不会泄漏一个字节，那么内存失败的几率将会增大。有多少应用程序（特别是那些内部开发的应用程序）能够提供这种保证呢？

如果您不检查该返回指针值是否为 NULL 的理由是运算符 new 将会引发一个异常，那么还有情可原。毕竟，C++ 标准规定 new 在失败时应引发异常。这不是直到 6.0 的所有版本 Visual C++（不使用 MFC 时）的默认实现，该实现在失败时将返回 NULL。这在 Visual C++ .NET 中得到了解决，但先前的实现（特别是使用 STL 时）可能会出现问题。STL 实现假定 new 失败时将引发异常，不管使用什么编译器。事实上，如果 new 没有出现这种行为并且内存分配失败，返回 NULL ，那么就没有定义 STL 行为，并且很可能将导致应用程序崩溃。我马上将为您展示一个具体的示例。

标准模板库

越来越多的开发人员依赖 STL 进行 C++ 开发。STL 提供了丰富的基于 C++ 模板的类和函数。在应用程序中使用 STL 有几个好处。首先，该库为多种通用任务提供了一致的接口。第二个好处是，该代码已经被广泛测试，并有理由认为代码中没有错误。最后，其算法是最佳的。

为了使 STL 工作，宿主编译器必须实现 STL 所写入到的 C++ 标准。Visual C++ 编译器预包装有 STL 实现，还可使用很多其他供应商的实现。

Visual C++ 6.0 和运算符 New

当运算符 new 失败返回 NULL 时，可以认为这是个错误，因为这与声明在失败时运算符 new 应当引发异常的标准背道而驰。我所了解的所有 STL 实现，包括 Visual C++ 随附的版本，都期望运算符 new 在失败时会引发异常。

虽然改变运算符 new在失败时引发异常的行为是有可能的，我将在后面说明这一点，但这本身将导致进一步的异常。首先，我将说明在默认环境下运算符 new 失败时会发生什么情况。我的所有测试都是利用运行于 Windows NT®4.0 Service Pack 6a 和 Windows®2000 SP2 下的 Visual C++ 6.0, SP4 和 SP5 进行的。据我所知，这种行为将会影响用任何版本的 Visual C++ 编译器（6.0 SP5 版本或更高版本）在所有操作系统上构建的代码。利用 Visual C++ 版本 7.0 和 7.1 已经测试了同样的代码，这两种版本都显示了运算符 new 失败时符合标准的行为。使用的 STL 库是 Visual C++ 和 STLPort (http://www.stlport.org) 实现随附的版本。

为了解释 STL，我将使用最常用的 STL 类 std::string，尽管描述的行为适用于任何为运算符 new 分配堆内存的 STL 函数或类。在该示例中，我们假定试图用一些数据构造一个新的字符串对象，并且堆分配将会失败。下列代码片断将可以满足要求：

图 2 中的代码摘自 Visual C++ 6.0 随附的 STL 字符串类代码。构造函数最终引起 std::basic_string<>::_Copy。 图 2 中显示的是其中的一部分，删除了部分代码。在 try 块中，局部变量 _S 被赋给 allocator.allocate 的返回值，反过来，它调用运算符 new。对于默认的 Visual C++ 6.0 行为，在失败时运算符 new 将返回 NULL 值，这导致 NULL 值被赋给局部变量 _S。关键是没有引发异常。

要执行的下一行代码是将 _S + 1 赋值给成员变量 _Ptr。因为 _S 的值为 NULL，值 0x00000001 将被赋给变量 _Ptr。接下来的一行，_Refcnt( Ptr) = 0，有效地返回 _Ptr - 1（实际为 _Ptr[-1]），它根据由运算符 new 返回的原始 NULL 指针值进行求值。_Refcnt 成员函数返回对 NULL 指针第一个元素的引用，而随后将 0 赋给该引用（本质是 *NULL= 0），由于即时访问冲突该引用将失败。除了安装结构化异常处理程序来捕捉该错误这样极其苛刻的措施外，并没有办法制止由于访问冲突而终止应用程序。虽然这种行为好像是由错误引起的，STL 代码实际上也是正确的，但为了得到正确的行为，它要求运算符 new 在失败时引发异常。

现在让我们看一下在运算符 new 失败引发异常时的执行流程。如前面所示，将执行对 allocator.allocate 的初始调用。当运算符 new 失败时，引发 std::bad alloc 异常，代码引起 catch(...) ( CATCH ALL) 处理程序，该处理程序重新尝试分配，请求的内存可能会较小。如果第二次分配失败，将进一步引发 std::bad alloc 异常，这将传播回代码，使 std::string 对象为已定义的空状态。

应注意该重载的字符串构造函数可能会引发异常。如果构建的类有 std::string 成员变量，在构造函数的初始化部分将调用该类的重载构造函数，应仔细阅读 Robert Schmidt 的“Handling Exceptions, Part 10”的 Deep C++ 专栏。

修复运算符 New

前面我提到不应按照知识库文章 167733 中给出的实现来修复引发异常的运算符 new。本文给出两个代码示例，如图 3 和图 4 所示。第一个示例正确地安装了一个新的（用于运算符 new 失败）处理程序，我将改进该处理程序以给出一个自动安装的处理程序。第二个示例是我为什么给出警告。该示例安装了一个新的处理程序，并调用 _set_new_mode(1) 以表明 malloc 应在失败时引发异常。

如果设置 malloc 在失败时引发异常，则使用 malloc 的所有代码都会对此行为“感到惊讶”。运算符 new(std::nothrow) 也可以按照 malloc 来实现（至少对于调试版本是这样），这种变化将导致运算符 new(std::nothrow) 在失败时引发异常。这肯定不是您想要的行为。

图 5 显示了自动安装的新处理程序的代码，这些代码包含在随本文一起提供的 NewHandler.cpp 源文件中（参见本文顶部的链接）。本质上，它与知识库文章（如图 4 所示）中列出的第二个示例代码相同，语法已修复，并且删除了 _set_new_mode 调用。通过将 NewHandler.cpp 文件添加到您的项目中可使用这些代码。

该处理程序的测试工具程序非常简短，如图 6 所示。在大多数计算机上，该测试代码的分配将会引起即时失败。示例代码导致非法的堆分配大小，无需实际执行分配即导致立即失败。遗憾的是，如果您持续分配了大块的内存，直到实际堆分配发生失败，您将不能对代码进行调试，因为 Visual C++ IDE 在内存不足的情况下总是要崩溃的。为了构建该测试程序，下载示例文件。在 Visual C++ 6.0 中打开 Testnew_throw.cpp 文件，从 Build 菜单选择 Build。接受创建一个默认工作区的提示。如果逐句调试代码，您会验证现在在失败时运算符 new 将引发 std::bad_allocc 类型的异常。

不管怎样，当运算符 new(std::nothrow) 引发异常时

在知识库文章的结尾，关于运算符 new(std::nothrow) 和 Visual C++ 5.0 的注意事项中指出：如果安装新的处理程序，则 new(std::nothrow) 将引发异常。在 Visual C++ 6.0 中仍然存在这个问题，但其行为更微妙。利用 Visual C++ 6.0，当只与 Debug 运行库链接时，运算符 new(std::nothrow) 在失败时的行为才和期望的一样，并返回 NULL。如果您链接运行库的 Release 版，那么运算符 new(std::nothrow) 总会引发异常。这当然不是应用程序所想要的行为。运算符 new(std::nothrow) 的测试工具程序非常简短，但由于另外的突发事件（这里是优化的编译器），对全部行为的演示并不是那么简单明了。该测试程序最主要的部分是 try 块中仅有的调用运算符 new(std::nothrow) 的代码，如图 7 所示。

利用与 Testnew_throw.cpp 相同的方法，构建该测试程序的 Win32® Debug 配置。运行产生的可执行文件，得到下面的期望结果：

现在构建 Win32 Release 配置，运行产生的可执行文件。输出结果可能会出人意料：

这里有一件事是确定的：运算符 new(std::nothrow) 肯定不返回 NULL。究竟发生什么不是那么清楚。试着将该行移到 try 块内：

结果发生了变化：

现在调用 catch 处理程序，来证实我前面提到的发布构建行为。问题仍然存在：为什么以前得到一个异常的程序终止？为了看清楚正在发生的一切，首先恢复到如图 7 所示的原始代码（只有对 try 块中运算符 new(std::nothrow) 的调用）。接着，更改 Win32 Release 配置的项目设置以禁用编译器优化操作 (Project | Settings | C/C++ | General | Optimizations = Disable (Debug))。构建并运行该可执行文件。程序的输出结果是预期的，但仍不是您想要的：

该行为可归于优化的编译器，它实际上生成有效的编译代码。Visual C++ 6.0 文档规定：尽管编译器支持异常规范的语法，它仍将忽略它们。因此，这不严格为真。要看清楚正在发生的一切，必须深入研究生成的程序集代码（非常少）。保留禁用优化设置，并确保 try 块中的唯一一行代码是对运算符 new(std::nothrow) 的调用，打开混合的程序集代码 (Project | Settings | C/C++ | Listing Files | Listing file type = Assembly with Source Code)。构建可执行文件，打开位于 Release 文件夹中的生成文件 Testnew_nothrow.asm。在该文件中，搜索字符串“try”，确保选中了“Find whole word only”复选框，避免与其他实例的部分匹配。应该能够查看 try 块的混合源程序/程序集，包括一个对名称为 __$EHRec$ 变量的引用。这是为 try/catch 异常机制生成的部分代码。

接下来，重新打开优化设置，重新生成并定位 Testnew_nothrow.asm 文件中的“try”源程序行。对 __$EHRec$ 变量的引用没有了。已经发生的事情是优化编译器检测到运算符 new(std::nothrow) 被声明为不引发异常，并正确地推断出整个 try/catch 块是冗余代码。结果是整个 try/catch 块被优化，使得由 try 块包装的代码无需多余的异常处理支持就可运行。虽然这在技术上是正确的，但会与随后编译器允许非引发函数引发一个异常相矛盾，而非引发函数是不可能捕获异常的。

已经发现了运算符 new(std::nothrow) 所进行的操作，现在我以用户提供的运算符 new(std::nothrow) 版本来给出该问题的修复方法。该方法取自知识库文章 167733，并包括在 NewNoThrow.cpp 源文件中，该文件可从本文下载的代码得到。该版本在失败时将正确地返回 NULL：

但这需要警告语句。如果链接 DLL 版本的运行库（调试多线程 DLL 或多线程 DLL），则新的处理程序会有效地安装到运行库 DLL 中。这意味着加载到进程地址空间并与匹配版本的运行库 DLL 链接的任一 DLL 文件，都将受到该处理程序的影响（new 在失败时将引发异常）。这其中的含意完全取决于客户端 DLL 是否希望 new 返回 NULL 或认为它将引发异常（ATL 对两种模式都支持）。

只有在 new 更改为引发异常时才需要修复运算符 new(std:nothrow)，这样的更改对正确使用 STL 是强制性的。但是，这种修复对于源文件要插入到的项目来说是局部的。在这种情况下，任何使用运算符 new(std::nothrow) 并构建兼容版本的运行库 DLL 的第三方 DLL（如我前面所显示的）都将存在失败时 new(std::nothrow) 引发异常的危险。这之所以发生是因为全局范围的新处理程序与局部范围的替换运算符 new(std::nothrow) 不匹配。唯一可行的解决方案是链接一个静态运行时库，或者验证第三方代码不会调用运算符 new(std::nothrow)，或者不链接 DLL 版本的运行库。如果说这种不幸的事件状态有可能补救，那一定是运算符 new(std::nothrow) 很少重载使用。

最后的补救就是求助于 Visual C++ 6.0 提供的 STL，实际上只在一个地方使用这种重载，也就是 get_temporary_buffer 模板函数。您的代码不太可能直接调用该函数。但是，通过对 STL 源代码进行的搜索显示，internal_Temp_iterator 模板类调用 get_temporary_buffer 模板函数。下列在算法中定义的公共函数间接调用 _Temp_iterator 模板类自身：stable_partition、stable_sort 和 inplace_merge。如果运算符 new(std::nothrow) 确实引发了异常，则这些函数的行为没有被定义。如果使用这些函数并且安装了新处理程序，那么可以考虑使用不同的 STL 实现，其中有很多实现都可以使用。我在工作中成功地使用了 STLPort (http://www.stlport.org)。据我所知，该实现在其实现中的任何地方都没有调用运算符 new(std::nothrow)。

小结

我已经说明了如果您正在非 MFC 项目中使用 Visual C++（最高至 6.0 版本）中的 STL，其即装即用的行为可能导致在内存不足的情况下 STL 使您的应用程序崩溃。Visual C++ 6.0 提供的运算符 new 版本与 STL 不兼容。即使这里提供了修复方法，但当使用第三方代码或者 Visual C++ 6.0 提供的 STL 版本中的某些函数时，仍有可能出现麻烦。目前 Visual C++ 6.0 中运算符 new、运算符 new(std::nothrow) 和 STL 之间的不匹配不能完全被修复。但是，如果您在代码中使用 STL，而且没有包含我在本文中推荐的修复方法，您的应用程序在内存不足的情况下就会处于 STL 代码崩溃的真实危险中。

对于基于 MFC 的项目，STL 是否会在运算符 new 内幸免于难，完全取决于您使用的 STL 实现如何处理该运算符的异常。在处理失败的分配时，大多数实现好像都使用 catch(...)，而并不使用 catch(std::bad alloc)，但并不是必需这样。

最后，正如我在本文开始部分所述，两个目前使用的 Visual C++ .NET 版本都已解决了我所提到的所有问题，除了 MFC 行为之外。

相关文章，请参阅：
Handling Exceptions in C and C++, Part 1
Visual C++ Developer Center
http://www.stlport.org

James Hebben 是一位立足于英国的顾问，专门从事于 Visual C++ 财务和贸易系统 (http://www.extraview.uk.com)。可以发送电子邮件到 James.hebben@extraview.uk.com 与他联系。