What if new throws exeption?

[doublemaster007]

Hi All

somePtr *obj =NULL; ----------------------------(1)
obj = new somePtr; -----------------------------(2)

if(obj!=NULL) ------------------------------(3)
{
//do somthing
}

Is this code correct?
first, "new" doesnt return NULL. I have read this some where. Or is
that (1) ensures obj NULL after (2)
AFAIK, new throws exeption. So will the (3) be exexuted?

Reason i am asking this is, Its become a practise that checking for
NULL instead of trying for exeption. Is the above code really correct?

One more question. If new fails, Do we need to call the destructor of
obj explicitly?? AFAIK objected isnt contructed so we donot need to
call destructor..am i right???

 

[Kenshin]

Hi All

somePtr *obj =NULL;            ----------------------------(1)
obj = new somePtr;              -----------------------------(2)

if(obj!=NULL)                       ------------------------------(3)
{
 //do somthing

}

Is this code correct?
first, "new" doesnt return NULL. I have read this some where. Or is
that  (1) ensures obj NULL after (2)
AFAIK, new throws exeption. So will the (3) be exexuted?

Reason i am asking this is, Its become a practise that checking for
NULL instead of trying for exeption. Is the above code really correct?

One more question. If new fails, Do we need to call the destructor of
obj explicitly??  AFAIK objected isnt contructed so we donot need to
call destructor..am i right???

And herein is the power of smart pointers made manifest:

std::scoped_ptr<somePtr> obj(new somePtr);

if(obj){

 

[Vladimir Jovic]

Hi All

somePtr *obj =NULL; ----------------------------(1)
obj = new somePtr; -----------------------------(2)

if(obj!=NULL) ------------------------------(3)
{
//do somthing
}

Is this code correct?

Maybe. I can not compile it. See this:
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8

first, "new" doesnt return NULL. I have read this some where. Or is
that (1) ensures obj NULL after (2)
AFAIK, new throws exeption. So will the (3) be exexuted?

If (2) throws an exception, then (3) will not be executed.

Reason i am asking this is, Its become a practise that checking for
NULL instead of trying for exeption. Is the above code really correct?

That practice is for C, not for c++. In c++ you check for the exception.

One more question. If new fails, Do we need to call the destructor of
obj explicitly?? AFAIK objected isnt contructed so we donot need to
call destructor..am i right???

No and yes.
1) No - for call the destructor. In 99.999% cases you do not need to
call destructor explicitly. Specially in this case
2) Yes - you are right

 

[James Kanze]

somePtr *obj =NULL; ----------------------------(1)
obj = new somePtr; -----------------------------(2)

if(obj!=NULL) ------------------------------(3)
{
//do somthing
}

Is this code correct?

In what sense? It's certainly legal. If there's nothing between (2)
and (3), however, the if is guaranteed to be true.

first, "new" doesnt return NULL. I have read this some where. Or is
that (1) ensures obj NULL after (2) AFAIK, new throws exeption. So
will the (3) be exexuted?

More context is needed. There are definitely cases where something
like:

SomeType* obj = NULL;
try {
obj = new SomeType;
// ... do something with obj...
} catch (...) {
// do something else...
}
// obj is still in scope here...
delete obj;

but they aren't frequent. (At all, in fact. I'd qualify them as
rare.)

Reason i am asking this is, Its become a practise that checking for
NULL instead of trying for exeption. Is the above code really correct?

You don't check for null after new, and you don't "try for an
exception": you get an exception if there is not enough memory (unless
you've set the new_handler to do something else, like abort), and your
code should be able to deal with it.

One more question. If new fails, Do we need to call the destructor of
obj explicitly?? AFAIK objected isnt contructed so we donot need to
call destructor..am i right???

Obviously. The constructor can't be called until the memory is
allocated. If allocation fails, the constructor is never called.

 

[Vladimir Jovic]

And herein is the power of smart pointers made manifest:

std::scoped_ptr<somePtr> obj(new somePtr);

if(obj){

Can you explain how the power of smart pointers is manifested in your
code snippet? The "if" statement will not be executed.

 

[Kenshin]

Hi All

somePtr *obj =NULL;            ----------------------------(1)
obj = new somePtr;              -----------------------------(2)

if(obj!=NULL)                       ------------------------------(3)
{
 //do somthing

}

Is this code correct?
first, "new" doesnt return NULL. I have read this some where. Or is
that  (1) ensures obj NULL after (2)
AFAIK, new throws exeption. So will the (3) be exexuted?

Reason i am asking this is, Its become a practise that checking for
NULL instead of trying for exeption. Is the above code really correct?

One more question. If new fails, Do we need to call the destructor of
obj explicitly??  AFAIK objected isnt contructed so we donot need to
call destructor..am i right???

And herein is the power of smart pointers made manifest:

//BEGINNINOF SOME SCOPE//

std::unique_ptr<somePtr> obj(new somePtr);

if(obj){

obj->call_method(); //use as though raw pointer//
function(obj.get()/*, other_arguments */); //function takes raw
pointer, so obj.get() returns contained pointer//

}

return obj.release(); //relinquishes ownership of raw pointer, better
to return smart pointer//

//END OF SOME SCOPE// //raw pointer automatically deleted//

The smart pointer (auto (avoid), scoped, unique, shared, weak) takes
care of all your worries, or at least 99% (keeping in mind the pitfall
of using shared pointer temporaries).

 

[Vladimir Jovic]

You don't check for null after new, and you don't "try for an
exception": you get an exception if there is not enough memory (unless
you've set the new_handler to do something else, like abort), and your
code should be able to deal with it.

What I thought is this :
In the end (somewhere in main()), you should check for std::bad_alloc or
std::exception, and log the error/inform the user, and clean up nicely.
Instead of just letting the exception kill your program.

 

[Rolf Magnus]

What I thought is this :
In the end (somewhere in main()), you should check for std::bad_alloc or
std::exception, and log the error/inform the user, and clean up nicely.
Instead of just letting the exception kill your program.

A good compiler will already provide that, including more information than
you can get in a standard C++ program, like e.g. a backtrace.

 

[Vladimir Jovic]

A good compiler will already provide that, including more information than
you can get in a standard C++ program, like e.g. a backtrace.

void a()
{
int *p = new int[1000000];
}
void b()
{
for(int i=0; i<1000000;++i)
{
int *a = new int[1000000];
}
}
int main()
{
a();
b();
}


This example gives just this:

terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted

I compiled the example using g++ 4.3.0, which I find good enough.

 

[John H.]

Reason i am asking this is, Its become a practise that checking for
NULL instead of trying for exeption. Is the above code really correct?

Yes the standard way for new to fail due to lack of memory is to throw
an exception. There was at least one popular C++ compiler (I think
MSVC++ 6.0) that returned a null pointer. In addition, you can get
this behavior in a more standard way by using the no throw new:

#include <new>
int main()
{
double * p = new(std::nothrow) double[99999999];
if(p == NULL)
{
// chance to do some error handling
}
delete[] p;
return 0;
}

 

[James Kanze]

Yes the standard way for new to fail due to lack of memory is to throw
an exception. There was at least one popular C++ compiler (I think
MSVC++ 6.0) that returned a null pointer.

There *were* a lot of C++ compilers which returned a null pointer.
Back
in 1990, when I was learning C++, all of them, in fact.

What makes VC++ 6.0 special in this regard is that it is still being
used. This isn't true for any of the other compilers which returned a
null pointer. (One might ask why it is still being used. Microsoft
has
a number of more recent versions, which are not only closer to the
standard, but fix a number of real bugs.)