改善C++ 程序的150个建议学习之建议30：new内存失败后的正确处理
2013-09-13 09:35
381 查看
建议30：new内存失败后的正确处理
应该有很多的程序员对比尔•盖茨的这句话有所耳闻：对于任何一个人而言，640KB应当是足够的了。（640K ought to be enough for everybody.）
不幸的是，伟大的比尔•盖茨也失言了。随着硬件水平的发展，内存变得越来越大，但是似乎仍不能满足人们对内存日益增长的需求。所以呢，我们C/C++程序员在写程序时也必须考虑一下内存申请失败时的处理方式。通常，我们在使用new进行内存分配的时候，会采用以下的处理方式：
char *pStr = new string[SIZE];
if(pStr == NULL)
{
... // Error processing
return false;
}
你能发现上述代码中存在的问题吗？这是一个隐蔽性极强的臭虫（Bug）。我们沿用了C时代的良好传统：使用 malloc 等分配内存的函数时，一定要检查其返回
值是否为“空指针”，并以此作为检查分配内存操作是否成功的依据，这种Test-for-NULL代码形式是一种良好的编程习惯，也是编写可靠程序所必需的。可是，这种完美的处理形式必须有一个前提：若new失败，其返回值必须是NULL。只有这样才能保证上述看似“逻辑正确、风格良好”的代码可以正确运行。那么new失败后编译器到底是怎么处理的？在很久之前，即C++编译器的蛮荒时代，C++编译器保留了C编译器的处理方式：当operator new不能满足一个内存分配请求时，它返回一个NULL 指针。这曾经是对C的malloc函数的合理扩展。然而，随着技术的发展，标准的更新，编译器具有了更强大的功能，类也被设计得更漂亮，新时代的new在申请内存失败时具备了新的处理方式：抛出一个bad_alloc
exception（异常）。所以，在新的标准里，上述Test-for-NULL处理方式不再被推荐和支持。如果再回头看看本建议开头的代码片段，其中的 if (pStr == 0 )从良好的代码风格突然一下变成了毫无意义。在C++里，如果 new 分配内存失败，默认是抛出异常。所以，如果分配成功，pStr == 0就绝对不会成立；而如果分配失败了，也不会执行if ( pStr == 0 )，因为分配失败时，new 就会抛出异常并跳过后面的代码。为了更加明确地理解其中的玄机，首先看看相关声明：
namespace std
{
class bad_alloc
{
// ...
};
}
// new and delete
void *operator new(std::size_t) throw(std::bad_alloc);
void operator delete(void *) throw();
// array new and delete
void *operator new[](std::size_t) throw(std::bad_alloc);
void operator delete[](void *) throw();
// placement new and delete
void *operator new(std::size_t, void *) throw();
void operator delete(void *, void *) throw();
// placement array new and delete
void *operator new[](std::size_t, void *) throw();
void operator delete[](void *, void *) throw();
在以上的new操作族中，只有负责内存申请的operator new才会抛出异常std::bad_alloc。如果出现了这个异常，那就意味着内存耗尽，或者有其他原因导致内存分配失败。所以，按照C++标准，如果想检查 new 是否成功，则应该捕捉异常：
try
{
int* pStr = new string[SIZE];
... // processing codes
}
catch ( const bad_alloc& e )
{
return -1;
}
但是市面上还存在着一些古老编译器的踪迹，这些编译器并不支持这个标准。同时，在这个标准制定之前已经存在的很多代码，如果因为标准的改变而变得漏洞百出，肯定会引起很多人抗议。C++标准化委员会并不想遗弃这些 Test-for-NULL的代码，所以他们提供了operator new 的另一种可选形式— nothrow ，用以提供传统的Failure-yieldsNULL行为。其实现原理如下所示：
void * operator new(size_t cb, const std::nothrow_t&) throw()
{
char *p;
try
{
p = new char[cb];
}
catch (std::bad_alloc& e)
{
p = 0;
}
return p;
}
<new> 文件中也声明了nothrow new的重载版本，其声明方式如下所示：
namespace std
{
struct nothrow_t
{
// ...
};
extern const nothrow_t nothrow;
}
// new and delete
void *operator new(std::size_t, std::nothrow_t const &) throw();
void operator delete(void *, std::nothrow_t const &) throw();
// array new and delete
void *operator new[](std::size_t, std::nothrow_t const &) throw();
void operator delete[](void *, std::nothrow_t const &) throw();
如果采用不抛出异常的new形式，本建议开头的代码片段就应该改写为以下形式：
int* pStr = new(std::nothrow) string[SIZE];
if(pStr==NULL)
{
... // 错误处理代码
}
根据建议29可知，编译器在表达式 new (std::nothrow) ClassName中一共完成了两项任务。首先，operator new 的 nothrow 版本被调用来为一个ClassName object分配对象内存。假如这个分配失败，operator new返回null指针；假如内存分配成功，ClassName 的构造函数则被调用，而在此刻，对象的构造函数就能做任何它想做的事了。如果此时它也需要new一些内存，但是没有使用 nothrow new形式，那么，虽然在"new (std::nothrow)
ClassName"中调用的operator new 不会抛出异常，但其构造函数却无意中办了件错事。假如它真的这样做了，exception就会像被普通的operator new抛出的异常一样在系统里传播。所以使用
nothrow new只能保证operator new不会抛出异常，无法保证"new (std::nothrow) ClassName"这样的表达式不会抛出exception。所以，慎用nothrow new。
最后还需要说明一个比较特殊但是确实存在的问题：在Visual C++ 6.0 中目前operatornew、operator new(std::nothrow) 和 STL 之间不兼容、不匹配，而且不能完全被修复。如果在非MFC项目中使用Visual C++6.0中的STL，其即装即用的行为可能导致STL在内存不足的情况下让应用程序崩溃。对于基于MFC的项目，STL是否能够幸免于难，完全取决于你使用的 STL 针对operator new的异常处理。这一点，在James Hebben的文章《不要让内存分配失败导致您的旧版
STL 应用程序崩溃》中进行了详细的介绍，如果你在使用古老的Visual C++ 6.0编译器，而且对这个问题充满兴趣，请Google之。
请记住：当使用new申请一块内存失败时，抛出异常std::bad_alloc是C++标准中规定的标准行为，所以推荐使用try{ p = new int[SIZE]; } catch( std::bad_alloc ) { ... }的处理方式。但是在一些老旧的编译器中，却不支持该标准，它会返回NULL，此时具有C传统的Test_for_NULL代码形式便起了作用。所以，要针对不同的情形采取合理的处置方式。
应该有很多的程序员对比尔•盖茨的这句话有所耳闻：对于任何一个人而言，640KB应当是足够的了。（640K ought to be enough for everybody.）
不幸的是，伟大的比尔•盖茨也失言了。随着硬件水平的发展，内存变得越来越大，但是似乎仍不能满足人们对内存日益增长的需求。所以呢，我们C/C++程序员在写程序时也必须考虑一下内存申请失败时的处理方式。通常，我们在使用new进行内存分配的时候，会采用以下的处理方式：
char *pStr = new string[SIZE];
if(pStr == NULL)
{
... // Error processing
return false;
}
你能发现上述代码中存在的问题吗？这是一个隐蔽性极强的臭虫（Bug）。我们沿用了C时代的良好传统：使用 malloc 等分配内存的函数时，一定要检查其返回
值是否为“空指针”，并以此作为检查分配内存操作是否成功的依据，这种Test-for-NULL代码形式是一种良好的编程习惯，也是编写可靠程序所必需的。可是，这种完美的处理形式必须有一个前提：若new失败，其返回值必须是NULL。只有这样才能保证上述看似“逻辑正确、风格良好”的代码可以正确运行。那么new失败后编译器到底是怎么处理的？在很久之前，即C++编译器的蛮荒时代，C++编译器保留了C编译器的处理方式：当operator new不能满足一个内存分配请求时，它返回一个NULL 指针。这曾经是对C的malloc函数的合理扩展。然而，随着技术的发展，标准的更新，编译器具有了更强大的功能，类也被设计得更漂亮，新时代的new在申请内存失败时具备了新的处理方式：抛出一个bad_alloc
exception（异常）。所以，在新的标准里，上述Test-for-NULL处理方式不再被推荐和支持。如果再回头看看本建议开头的代码片段，其中的 if (pStr == 0 )从良好的代码风格突然一下变成了毫无意义。在C++里，如果 new 分配内存失败，默认是抛出异常。所以，如果分配成功，pStr == 0就绝对不会成立；而如果分配失败了，也不会执行if ( pStr == 0 )，因为分配失败时，new 就会抛出异常并跳过后面的代码。为了更加明确地理解其中的玄机，首先看看相关声明：
namespace std
{
class bad_alloc
{
// ...
};
}
// new and delete
void *operator new(std::size_t) throw(std::bad_alloc);
void operator delete(void *) throw();
// array new and delete
void *operator new[](std::size_t) throw(std::bad_alloc);
void operator delete[](void *) throw();
// placement new and delete
void *operator new(std::size_t, void *) throw();
void operator delete(void *, void *) throw();
// placement array new and delete
void *operator new[](std::size_t, void *) throw();
void operator delete[](void *, void *) throw();
在以上的new操作族中，只有负责内存申请的operator new才会抛出异常std::bad_alloc。如果出现了这个异常，那就意味着内存耗尽，或者有其他原因导致内存分配失败。所以，按照C++标准，如果想检查 new 是否成功，则应该捕捉异常：
try
{
int* pStr = new string[SIZE];
... // processing codes
}
catch ( const bad_alloc& e )
{
return -1;
}
但是市面上还存在着一些古老编译器的踪迹，这些编译器并不支持这个标准。同时，在这个标准制定之前已经存在的很多代码，如果因为标准的改变而变得漏洞百出，肯定会引起很多人抗议。C++标准化委员会并不想遗弃这些 Test-for-NULL的代码，所以他们提供了operator new 的另一种可选形式— nothrow ，用以提供传统的Failure-yieldsNULL行为。其实现原理如下所示：
void * operator new(size_t cb, const std::nothrow_t&) throw()
{
char *p;
try
{
p = new char[cb];
}
catch (std::bad_alloc& e)
{
p = 0;
}
return p;
}
<new> 文件中也声明了nothrow new的重载版本，其声明方式如下所示：
namespace std
{
struct nothrow_t
{
// ...
};
extern const nothrow_t nothrow;
}
// new and delete
void *operator new(std::size_t, std::nothrow_t const &) throw();
void operator delete(void *, std::nothrow_t const &) throw();
// array new and delete
void *operator new[](std::size_t, std::nothrow_t const &) throw();
void operator delete[](void *, std::nothrow_t const &) throw();
如果采用不抛出异常的new形式，本建议开头的代码片段就应该改写为以下形式：
int* pStr = new(std::nothrow) string[SIZE];
if(pStr==NULL)
{
... // 错误处理代码
}
根据建议29可知，编译器在表达式 new (std::nothrow) ClassName中一共完成了两项任务。首先，operator new 的 nothrow 版本被调用来为一个ClassName object分配对象内存。假如这个分配失败，operator new返回null指针；假如内存分配成功，ClassName 的构造函数则被调用，而在此刻，对象的构造函数就能做任何它想做的事了。如果此时它也需要new一些内存，但是没有使用 nothrow new形式，那么，虽然在"new (std::nothrow)
ClassName"中调用的operator new 不会抛出异常，但其构造函数却无意中办了件错事。假如它真的这样做了，exception就会像被普通的operator new抛出的异常一样在系统里传播。所以使用
nothrow new只能保证operator new不会抛出异常，无法保证"new (std::nothrow) ClassName"这样的表达式不会抛出exception。所以，慎用nothrow new。
最后还需要说明一个比较特殊但是确实存在的问题：在Visual C++ 6.0 中目前operatornew、operator new(std::nothrow) 和 STL 之间不兼容、不匹配，而且不能完全被修复。如果在非MFC项目中使用Visual C++6.0中的STL，其即装即用的行为可能导致STL在内存不足的情况下让应用程序崩溃。对于基于MFC的项目，STL是否能够幸免于难，完全取决于你使用的 STL 针对operator new的异常处理。这一点，在James Hebben的文章《不要让内存分配失败导致您的旧版
STL 应用程序崩溃》中进行了详细的介绍，如果你在使用古老的Visual C++ 6.0编译器，而且对这个问题充满兴趣，请Google之。
请记住：当使用new申请一块内存失败时，抛出异常std::bad_alloc是C++标准中规定的标准行为，所以推荐使用try{ p = new int[SIZE]; } catch( std::bad_alloc ) { ... }的处理方式。但是在一些老旧的编译器中，却不支持该标准，它会返回NULL，此时具有C传统的Test_for_NULL代码形式便起了作用。所以，要针对不同的情形采取合理的处置方式。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 改善C++ 程序的150个建议学习之建议27：区分内存分配的方式
- 改善C++ 程序的150个建议学习之建议34：用智能指针管理通过new创建的对象
- 改善C++ 程序的150个建议学习之建议35：使用内存池技术提高内存申请效率与性能
- 改善C++ 程序的150个建议学习之建议28：new/delete与new[]/delete[]必须配对使用
- 改善C++ 程序的150个建议学习之建议31：了解new_handler的所作所为
- 改善C++ 程序的150个建议学习之建议18：正确区分void与void*
- 改善C++ 程序的150个建议学习之建议29：区分new的三种形态
- 改善C++ 程序的150个建议学习之建议32：借助工具监测内存泄漏问题
- 改善C++ 程序的150个建议学习之建议33：小心翼翼地重载operator new/ operator delete
- 改善C++ 程序的150个建议学习之建议2：避免那些由运算符引发的混乱
- 改善C++ 程序的150个建议学习之建议7：时刻提防内存溢出
- 改善C++ 程序的150个建议学习之建议15：尽量不要使用可变参数
- 改善C++ 程序的150个建议学习之建议25：尽量用const、enum、inline替换#define
- 改善C++ 程序的150个建议学习之建议20：使用memcpy()系列函数时要足够小心
- 改善C++ 程序的150个建议学习之建议8：拒绝晦涩难懂的函数指针
- 改善C++ 程序的150个建议学习之建议16：慎用goto
- 改善C++ 程序的150个建议学习之建议17：提防隐式转换带来的麻烦
- 改善C++ 程序的150个建议学习之建议3：对表达式计算顺序不要想当然
- 改善C++ 程序的150个建议学习之建议 9：防止重复包含头文件
- 改善C++ 程序的150个建议学习之建议22：灵活地使用不同风格的注释