3

In previous programs I have used the following code to check for memory allocation failures, usually without thinking about alternatives:

int* p_int = new int[10];
if(!p_int)
{
    // We failed, so exit
    return EXIT_FAILURE;
}

This method is also documented here.

I found here a reference for the syntax:

 p_int = (nothrow) new int[10];

Which suggests that if the programmer does not include the nothrow "argument" to new, then the check for nullptr is invalid? Is this correct? Or is it OS dependent?

As I understand it, there is little point putting new in a try-catch block unless you can actually recover from it because of the overhead associated with this. Is this also correct?

Undo
  • 25,519
  • 37
  • 106
  • 129
FreelanceConsultant
  • 13,167
  • 27
  • 115
  • 225

2 Answers2

3

Checking for nullptr after a new is useless because a failed new does not set the pointer to nullptr

int* p_int = new int[10];
if(!p_int)
{
    // error handling
}

Rather a failed new will throw a std::bad_alloc, so if you want to try to deal with it, you need to try and catch

try
{
    int* p_int = new int[10];
}
catch (const std::bad_alloc& e)
{
    std::cout << "Allocation failed: " << e.what();
    // deal with it
}
Cory Kramer
  • 114,268
  • 16
  • 167
  • 218
  • I am confused - why is it often suggested to check for `nullptr`? Is the second reference incorrect? – FreelanceConsultant Aug 23 '15 at 16:25
  • @user3728501 You should generally check if a pointer is `nullptr` before dereferencing it as good practice, I'm just saying in this scenario there is no way the pointer would become `nullptr`. The method using `nothrow` is **only true if you overload operator new** (e.g. you make an allocator pool or something), that means you would have to define your `new` to return `nullptr` and not throw. If you use the default `new` you cannot declare it to be `nothrow` because it can indeed throw. – Cory Kramer Aug 23 '15 at 16:28
  • 1
    @user3728501: It probably *was* often suggested before C++ was standardised or before exception support was a normal feature of a C++ compiler. That's now about 20 years ago. Times are changing, and C++ and the tools available for it nowadays are completely different. The article from 2007 which you cite is factually wrong, and its advice to "set all pointers pointing to the deleted memory to 0" is IMO complete nonsense. In general, go with cppreference.com for a good online reference, and get books from renowned C++ authors like Scott Meyers or Herb Sutter. – Christian Hackl Aug 23 '15 at 17:34
2

Yes, unless a no-throw version of new was used (and it was not overloaded to do something else!) it will never return null, and instead will throw an exception. And as for omnipresent check for null when dealing with pointers, this is usually a misguided thing. At most, it should be limited to debug builds. Since null pointers are just a narrow subclass of generally bad (non-dereferenceable) pointers, and they seldom appear in non-debug builds, checking for nulls is just CPU warm-up. For instance, library functions usually do not check their inputs for nulls.

SergeyA
  • 61,605
  • 5
  • 78
  • 137