Is it useful to test the return of "new" in C++?

Question

I usually never see test for new in C++ and I was wondering why.

Foo *f = new Foo;

// f is assumed as allocated, why usually, nobody test the return of new?

Answer 1

As per the current standard, new never returns NULL, it throws a std::bad_alloc instead. If you don't want new to throw(as per the old standard) but rather return NULL you should call it by postfixing it with "(std::nothrow)". i.e.

Foo* foo = new (std::nothrow) Foo;

Of course, if you have a very old or possibly broken toolchain it might not follow the standard.

Answer 2

Usually no one tests the return of new in new code because Visual Studio now throws the way the standard says.

In old code if a hack has been done to avoid throwing then you'd still better test.

Answer 3

It all depends which version of C++ the code targets. The c++ specification for a long time now has stated that, by default at least, failures in new will cause a c++ exception, so any code performing a test would be entirely redundant. Most programming nowadays also targets virtual memory operating systems where its almost impossible to run out of memory, AND an out-of-memory condition is so fatal anyway that just letting the application crash on the next NULL access is as good a way of any of terminating.

Its only really in embedded programming, where exception handling is deemed to be too much of an overhead, and memory is very limited, that programmers bother to check for new failures.

Answer 4

As quoted here

"In compilers conforming to the ISO C++ standard, if there is not enough memory for the allocation, the code throws an exception of type std::bad_alloc. All subsequent code is aborted until the error is handled in a try-catch block or the program exits abnormally. The program does not need to check the value of the pointer; if no exception was thrown, the allocation succeeded."

Answer 5

It all depends on your complier VC++ up to version 6 gives NULL if the new operator fails, on a non MFC application.

Now the problem gets bigger when you use for example STL with VC++ 6, because the STL goes with the standards it will never test for NULL when he needs to get some memory, and guess what will happen under low memory conditions....

So for everybody that still uses VC++ 6 and STL check this article for a Fix. Don't Let Memory Allocation Failures Crash Your Legacy STL Application

Answer 6

1. new throws std::bad_alloc by default. If you use default, checking for null is obsolete, but handling exceptions is necessary. This default behavior is consistent with C++ exception safety paradigm - it usually provides that an object is either constructed or not allocated

2. if you override default by using new (std::nothrow), checking on null is necessary. "New" both allocates and commits pages, so it is possible to run out of memory, either because you ran out of page descriptors, or because there's no physical memory available

3. research your OS's memory management. C/C++ reference machine does not know how your OS manages memory, so relying on language alone is not safe. For example of memory allocation gone bad, read on C malloc() + Linux overcommit