new 失败的问题c++ 标准 new 失败是抛出异常的，new(std::nothrow) 才返回 NULL为什么公司里面就都用 NULL
new 失败的问题
c++ 标准 new 失败是抛出异常的，new(std::nothrow) 才返回 NULL
为什么公司里面就都用 NULL 判断呢？ 好像公司里面好多人都不知道异常怎么用的？
有多少公司的代码是异常安全的？
求解？
看着他们的代码实在是头大
[解决办法]
因为好多公司都禁用异常.
[解决办法]
[解决办法]代码比较古老了 曾经的new是失败返回NULL的 而之所以现在又nothrow也是为了向下兼容
[解决办法]异常处理显得代码有些冗长，用NULL判断更方便些，在编码上少敲几个字母就是胜利了，不过条件不出错
[解决办法]C++的代码本来就不容易写，要追求异常安全就更难了。不过，对于申请内存来说，绝大多数程序，不太会失败。就算失败了，由于内存耗尽而crash的应用程序也可以接受。对于64位的应用来说，更是如此。因此，应用程序虽然异常不安全，但大多数情况下也能凑和着用。
[解决办法]没有思考过这个问题，翻了资料，
楼主说的是对的，抛出bad_alloc异常来，注：并没有说会返回null
只有 另外一个版本：
void* operator new(大小，nothrow); 这个分配失败才会返回NULL.
用法： int* p= new(nothrow) int;
if(p==NULL)
{
}
else
{
}
[解决办法]malloc倒是会 返回NULL.
教材害死人啊， 我记得我以前的教材也是这样检测的。
顺便问个问题， operator new(大小) operator new(大小，const std::nothrow&) thrown();
这两个版本 官方说，不需要包含什么头文件，什么原因？？？
平时我们用任何函数，都是需要包含头文件的， new 运算符的本质是调用 operator new函数。。。。
为什么不包含头文件呢???
[解决办法]这不都关键字了吗...
[解决办法]我们在大学学C++的时候都不讲异常处理的。。。都自己看得
[解决办法]我们的目的是为了让程序健壮，而不是出了点问题就让程序直接退出。
先弄清异常与错误的分别吧。
[解决办法]检查一下连接库用的是哪个版本的new
[解决办法]异常是很方便的功能，但并不是必须的功能
第一，较小的程序，架构较简单的程序，不必非要用异常
第二，异常机制是要消耗资源的，有些时候能省则省，例如《more effective c++》
[解决办法]new出错是要出异常的，因此后边的判断if (NULL == p)根本执行不到，只不过异常一般用的比较少而已
[解决办法]使用new ，然后判断返回是否为NULL的意义不大，除非你用的实际上是malloc
可以考虑用try() catch()
[解决办法]因为bad_alloc并不总是存在，C++允许编译器使用空异常规范的分配函数，这时候就只有NULL了。
[解决办法]这个问题我以前也疑惑过，按标准来说
int * p = new p;
if( p == NULL )
{
// 按照标准如果不指定nothrow，这里是不执行的
}
但事实是，我们的代码能正常执行，其实这个很多人都不知道，我在网上也问了很久，后来有人说，
这是编译器做的更改.微软的编译器，不管你指没指定nothrow，代码都是执行的，所以没有人去关注nothrow了。现在默认都是这样写的了。
[解决办法]主要是普通开发人员处理不好内存，而new这个东西，必然要编译器处理，系统就越做越多，干脆隐藏了动作。
[解决办法]不懂什么问题
[解决办法]楼上说 #define new new(std::nothrow)
mfc中的 new也是被重新定义了，貌似叫：DEBUG_NEW 吧，也是一个宏
你定义后，会和mfc冲突了，造成它的无效啊。
[解决办法]
nothrow 仅仅是在 new 的时候在有效。
在 呼叫构造函数时候，异常同样会抛出。
最好的方法就是像 ATL 那样。
[解决办法]
比较同意这个观点。
觉得对于公司来说，没有必要追求那么高质量的代码。
这些担心似乎有点多余。
int i = 0;
这个时候是否要去考虑i是否可以正确的分配到空间？
（这个例子举的很不恰当，i是在编译的时候就分配好了空间。大概说的是既然大部分不会失败，就不要去考虑那么多了。比如，程序这样运行1KW次，只失败一次。除非是软件有特殊要求）
相比中国大部分公司的软件质量基本不是很高。
中国有多少家软件公司符合UML提出的标准?百分比有多少？但是很多软件不也照样用么？
但是这样可能会有一个很可怕的后果，永远写不出非常高质量的代码。
