VC6下使用STL注意:不要让内存分配失败导致您的旧版STL 应用程序崩溃

核心提示：大多数 C++ 开发人员在他们的代码中都广泛使用了标准模块库 (STL)，如果您是其中的一员，VC6下使用STL注意:不要让内存分配失败导致您的旧版STL 应用程序崩溃，并且正在直接使用即装即用的 STL 和 Visual C++ 6.0，则在内存不足的条件下，那么就没有定义 STL 行为，并且很可能将导致应用程序崩溃

大多数 C++ 开发人员在他们的代码中都广泛使用了标准模块库 (STL)。如果您是其中的一员，并且正在直接使用即装即用的 STL 和 Visual C++ 6.0，则在内存不足的条件下，您的应用程序就处于崩溃的高度危险的状况下。产生此问题的原因是，检查运算符 new 是否失败是一种非常少见的做法。更糟糕的是，当 new 确实失败时，响应不是标准的。有些语言编译器返回 NULL，而其他语言则引发异常。

另外，如果您正在 MFC 项目中使用 STL，要注意 MFC 有其自己的规则集。本文将讨论这些问题，说明如何更改 Visual C++ .NET 2003 中的默认行为，并概述了如果使用 Visual C++ 6.0 所必须进行的更改，这样当运算符 new 失败时，您就可以安全地使用 STL 了。

有多少开发人员检查运算符 new 是否失败？有必要总是检查失败吗？我见过大型、复杂的用 Visual C++® 6.0 编写的 C++ 项目，其中在整个代码基中没有一项检查查看 new 是否返回 NULL。注意，我说的是检查 new 是否返回 NULL。在所有版本的 Visual C++（一直到版本 6.0）中，运算符 new 失败时的默认行为都是返回 NULL，而不是引发一个异常。（有关更多信息，请参见知识库文章 167733，但不要实现文中给出的解决方案。在本文后面我将解释为什么不应该实现解决方案）。

Visual C++ .NET 的默认行为已经更改，包括版本 7.0 (Visual C++ .NET 2002) 和 7.1 (Visual C++ .NET 2003)，当运算符 new 失败时，该行为会引发一个异常。虽然 Microsoft® .NET Framework 下的这种新行为遵循该 C++ 标准并深受欢迎，但需要注意，它可中断所有移植过来的 Visual C++ 6.0 样式代码的运行时行为，而这些代码不希望运算符 new 引发异常。如果您正在用 Visual C++ .NET 进行开发，您会发现这里产生的问题已经被解决。如果您还未使用某一种版本的 .NET Framework，本文将探究运算符 new 返回 NULL 时的隐含与不兼容等严重问题，这些问题适用于所有版本的 Visual C++ 编译器，包括 6.0 版本以及更高的版本。

背景

当 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 行为，并且很可能将导致应用程序崩溃。我马上将为您展示一个具体的示例。