Reputation: 16627
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?
Upvotes: 3
Views: 106
Reputation: 62573
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.
Upvotes: 2
Reputation: 117866
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
}
Upvotes: 3