Magos

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?

It's a bad habit I have, or?

__________________
MagosX.com

Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime.

nickname_changed

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.

Thantos

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.

okinrus

Some old compilers might return 0. The Dietel books check for both bad_alloc and null return, I think.

Ancient Dragon

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

Dave_Sinkula

http://www.parashift.com/c++-faq-lit....html#faq-16.6

__________________
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*

Ancient Dragon

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

Zach L.

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.

__________________
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.

adrianxw

>>> 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.

__________________
Wave upon wave of demented avengers march cheerfully out of obscurity unto the dream.

nickname_changed

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.

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.

Thantos

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.
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.

Sang-drax

will throw an exception if no memory is available (never return null).

will return 0 if no memory is available (provided that the header <new> is included and std::nothrow is used).

__________________
Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling

Zach L.

Fair enough.

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

__________________
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.

kawk

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.

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 .

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

dwks

Good advise. Why don't you follow it yourself?

__________________
dwk

Seek and ye shall find. quaere et invenies.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net

My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.