Thread: Bad coding habits

  1. #1
    Confused Magos's Avatar
    Join Date
    Sep 2001
    Location
    Sweden
    Posts
    3,145

    Bad coding habits

    I have a generally bad habit (I think) of always checking the return value from new.
    Code:
    SomeData* data = new SomeData();
    if(data == NULL)
    {
      //Error
    }
    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.

  2. #2
    Banned nickname_changed's Avatar
    Join Date
    Feb 2003
    Location
    Australia
    Posts
    986
    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.

  3. #3
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    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.

  4. #4
    Registered User
    Join Date
    Aug 2003
    Posts
    470
    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?
    Some old compilers might return 0. The Dietel books check for both bad_alloc and null return, I think.

  5. #5
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    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
    Last edited by Ancient Dragon; 09-08-2005 at 08:35 PM.

  6. #6
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,005
    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.*

  7. #7
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    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

  8. #8
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    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.

  9. #9
    It's full of stars adrianxw's Avatar
    Join Date
    Aug 2001
    Posts
    4,829
    >>> 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.

  10. #10
    Banned nickname_changed's Avatar
    Join Date
    Feb 2003
    Location
    Australia
    Posts
    986
    Quote Originally Posted by adrianxw
    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.

    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.

  11. #11
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Quote Originally Posted by stovellp
    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.
    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.

  12. #12
    S Sang-drax's Avatar
    Join Date
    May 2002
    Location
    Göteborg, Sweden
    Posts
    2,072
    Code:
    int* x = new int;
    will throw an exception if no memory is available (never return null).

    Code:
    int* x = new(nothrow) int;
    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

  13. #13
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    Quote Originally Posted by 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.
    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.

  14. #14
    C maniac
    Join Date
    Aug 2004
    Location
    Cyberwarping to Middle Earth
    Posts
    154
    Quote Originally Posted by Ancient Dragon
    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
    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 .

    Code:
    SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO);
    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
    Last edited by kawk; 09-12-2005 at 05:42 PM.

  15. #15
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    ... try to check for memory allocation that doesn't work.
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 6
    Last Post: 11-12-2005, 11:57 AM
  2. Poker bad beats
    By PJYelton in forum A Brief History of Cprogramming.com
    Replies: 21
    Last Post: 01-15-2005, 11:42 PM
  3. How bad is bad
    By caroundw5h in forum A Brief History of Cprogramming.com
    Replies: 21
    Last Post: 11-12-2004, 09:26 AM
  4. good news and bad news
    By Garfield in forum A Brief History of Cprogramming.com
    Replies: 25
    Last Post: 10-27-2001, 07:31 AM
  5. Bad code or bad compiler?
    By musayume in forum C Programming
    Replies: 3
    Last Post: 10-22-2001, 09:08 PM