Printable View
I have a generally bad habit (I think) of always checking the return value from new.
Is this completely worthless? If the system is out of memory (quite unlikely, but still) perhaps the program is forced to close, an exception is thrown or something?Code:SomeData* data = new SomeData();
if(data == NULL)
{
//Error
}
It's a bad habit I have, or?
Well if data is null and you attempt to use it, it should throw an exception anyway, which you could be handling in other ways. Personally, I wouldn't bother. If you do have an out-of-memory exception and the new doesn't work, you have much bigger problems.
IIRC new is required to throw an exception unless you use the nothrow option. The way you currently have it structured it is pretty pointless. However you can move to a try/catch structure to deal with memory problems.
Some old compilers might return 0. The Dietel books check for both bad_alloc and null return, I think.Quote:
Is this completely worthless? If the system is out of memory (quite unlikely, but still) perhaps the program is forced to close, an exception is thrown or something?
VC++ 6.0 does not throw an exception -- just returns NULL. But that is an old compiler that existed before current standards, so if you use that compiler don't rely on its behavior to be portable to others. And that is just one of the many many problems students come across while trying to learn the language on ancient compilers. and some universities even attempt to teach current c++ with compilers such as Turbo C and Turbo C++. Those two compilers existed long before there was a c++ standard. You wouldn't want an Model-T auto remairman to fix a 2006 car! So why would you want to learn c++ with ancient compilers :rolleyes:
That is kind of a two-faced explanation -- first it says that new never returns NULL, then turns around with the But's ...
Never say never
Checking for NULL isn't worthshile unless you have an old compiler (as stated above). In my opinion, there generally isn't too much point in trying to catch the exception. If you're out of memory, you're rather hosed anyway. Might as well let the program abort.
>>> Might as well let the program abort.
Why? In big programs with a lot of threads running which are allocating and deallocating memory all the time, if you can't grab the memory your thread needs now, why not back off for a few seconds and then try again. Better, control your memory pool with synchronisation objects.
That's really a different problem. In that case, I'd check for null. But the OP is talking about checking the return value every single time he uses new(). If you're writing a huge multithreaded business critical application, it's probably worth checking at critical points along the way, but in the majority of applications I wouldn't bother checking after every single memory assignment.Quote:
Originally Posted by adrianxw
Personally, I think a failed call to new() or malloc should throw an exception anyway, rather than just returning null. If you expect it to return null and handle it gracefully (though that would be hard considering you're out of memory) then wrap it in a try/catch.
Not necessarily. If you are on a machine with a heap and stack your heap could be fragmented such that it couldn't make the allocation of the size you wanted but you could still have plenty of stack space left.Quote:
Originally Posted by stovellp
And letting a program terminate due to an uncaught expection is just shoddy programming. Now it doesn't mean that every new needs to be wrapped in a try catch but it does mean that at some level you need to have a try catch that can deal with the problem.
will throw an exception if no memory is available (never return null).Code:int* x = new int;
will return 0 if no memory is available (provided that the header <new> is included and std::nothrow is used).Code:int* x = new(nothrow) int;
Fair enough.Quote:
Originally Posted by adrianxw
I was thinking along the lines of your program bogging down the system resources. Assuming that you can't recycle anything, at that point, there isn't much that can be done.
Chhers
I learnt to program on a DOS compiler, and wrote about 15 fairly good games on it. In fact I learnt from a 1993 book! So, I personally oppose that statement. So, maybe don't recommend it, but certiantly don't forbid it.Quote:
Originally Posted by Ancient Dragon
But, to get back on topic, I sometimes don't check for NULL, either :( .
But I always check on memory allocation :). That much I can boast, because I never use memory allocation :D .Code:SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO);
But, in C++, I actually never check. That's because the last time I used C++ with memory allocation was with my Athabasca University assignment (COMP307, TME4, to be exact. I got an A+ on it), and I never use C++ unless I can help it. Java, on the other hand, is a diffrent story, as I am just learning.
Anyway. The bottom line of this extra-long post is: try to check for memory allocation that doesn't work.
KAWK
Good advise. Why don't you follow it yourself? :)Quote:
... try to check for memory allocation that doesn't work.