bad_alloc in new

This is a discussion on bad_alloc in new within the C++ Programming forums, part of the General Programming Boards category; Hello everyone, I usually check whether there is bad_alloc thrown to identify whether the allocation is success or not. My ...

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    bad_alloc in new

    Hello everyone,


    I usually check whether there is bad_alloc thrown to identify whether the allocation is success or not.

    My question is,

    Is there a way to disable bad_alloc and just to check the returned pointer NULL or not to identify allocation success or not -- which from function point of view, is as correct as the way to catch bad_alloc? Windows platform/Visual Studio is ok. I always see code does not check bad_alloc and just check the return pointer.

    (My solution is to select Enable C++ Exception to No in Code Generation option in Visual Studio, not sure whether it is the most correct way.)


    thanks in advance,
    George

  2. #2
    Registered User
    Join Date
    Apr 2006
    Posts
    2,021
    To have new return a null pointer, instead of throwing an exception use nothow new.
    Code:
    #include <new>
    ...
    int *maybe_null = new(std::nothrow) int;
    In general it is best to use regular new, because in most cases there in nothing that a function can do about bad_alloc. Thus the exception would get propagated to something that can handle the problem, or if there isn't anything, quit.
    Last edited by King Mir; 01-27-2008 at 03:01 AM.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  3. #3
    Registered User
    Join Date
    Jun 2005
    Posts
    6,206
    You intended std::nothrow, I assume, King Mir.

  4. #4
    Registered User
    Join Date
    Apr 2006
    Posts
    2,021
    Yep, good catch.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  5. #5
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks King,


    No need to link with nothrownew.obj?

    Quote Originally Posted by King Mir View Post
    To have new return a null pointer, instead of throwing an exception use nothow new.
    Code:
    #include <new>
    ...
    int *maybe_null = new(std::nothrow) int;
    In general it is best to use regular new, because in most cases there in nothing that a function can do about bad_alloc. Thus the exception would get propagated to something that can handle the problem, or if there isn't anything, quit.

    regards,
    George

  6. #6
    Registered User
    Join Date
    Apr 2006
    Posts
    2,021
    <new> is part of the c++ standard library. So as long as you link to that, you're all set.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    No, that's a backward compatibility solution of MS.

    What King Mir showed is the standard way.

    Out of curiosity, what do you do when you've caught a bad_alloc?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  8. #8
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Hi King,


    Looks like we need to link with nothrownew.obj

    http://msdn2.microsoft.com/en-us/library/kftdy56f.aspx

    Quote Originally Posted by King Mir View Post
    <new> is part of the c++ standard library. So as long as you link to that, you're all set.

    regards,
    George

  9. #9
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    No, you don't. Use nothrow new. Don't make the normal new not throw with a stupid compiler workaround.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  10. #10
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    No need to link with nothrownew.obj? I have posted information in #8 of this thread, looks like MSDN is confusing. :-)

    Quote Originally Posted by CornedBee View Post
    No, that's a backward compatibility solution of MS.

    What King Mir showed is the standard way.

    Out of curiosity, what do you do when you've caught a bad_alloc?

    regards,
    George

  11. #11
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,

    1.

    The walkaround you mean link with nothrownew.obj?

    2.

    I want to confirm with you from my understanding that,

    I. using std::nothrow is using nothrow new (not normal new);
    II. linking with nothrownew.obj replaces the normal new?

    Quote Originally Posted by CornedBee View Post
    No, you don't. Use nothrow new. Don't make the normal new not throw with a stupid compiler workaround.

    regards,
    George

  12. #12
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,437
    Quote Originally Posted by George2 View Post
    1. The walkaround you mean link with nothrownew.obj?
    Yes!

    I. using std::nothrow is using nothrow new (not normal new);
    Yes!

    II. linking with nothrownew.obj replaces the normal new?
    Yes! Hence, workaround.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #13
    Registered User
    Join Date
    Jun 2005
    Posts
    6,206
    George,

    1) Yes, CornedBee's meant that "nothrownew.obj" is a compiler/vendor specific workaround. It also happens to be unnecessary, as the standard supports a non-throwing form of new.

    2 I) "new (std::nothrow) whatever" is what CornedBee was referring to as the "nothrow new". It is specified in the C++ standard.

    2 II) linking with nothrownew.obj replaces the "normal new"; it links in, in a compiler specific manner, an implementation of the non-placement operator new that behaves in a non-standard manner.

  14. #14
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Elysia and grumpy!


    Your help is great! My question is answered.

    Quote Originally Posted by grumpy View Post
    George,

    1) Yes, CornedBee's meant that "nothrownew.obj" is a compiler/vendor specific workaround. It also happens to be unnecessary, as the standard supports a non-throwing form of new.

    2 I) "new (std::nothrow) whatever" is what CornedBee was referring to as the "nothrow new". It is specified in the C++ standard.

    2 II) linking with nothrownew.obj replaces the "normal new"; it links in, in a compiler specific manner, an implementation of the non-placement operator new that behaves in a non-standard manner.

    regards,
    George

  15. #15
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    And if there's any part of the program that relies on new throwing, linking against nothrownew.obj will break this part. Which is why it's a stupid thing to do. You use this workaround only for programs written before new threw.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21