bad_alloc

This is a discussion on bad_alloc within the C++ Programming forums, part of the General Programming Boards category; You mean? Yes, that's the one, thus it was caught in the catch (int) exception handler....

  1. #16
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,632
    You mean?
    Yes, that's the one, thus it was caught in the catch (int) exception handler.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  2. #17
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks laserlight,


    My question is answered.

    Quote Originally Posted by laserlight View Post
    Yes, that's the one, thus it was caught in the catch (int) exception handler.

    regards,
    George

  3. #18
    Registered User
    Join Date
    Jan 2007
    Posts
    330
    Quote Originally Posted by CornedBee View Post
    Zero is a valid input to the allocator function.
    are you sure? I know in C that malloc(0) is implementation defined. Compilers are allowed to return NULL or a value not equalling NULL that can not be dereferenced.

    Is this different with C++'s new?

  4. #19
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Yeah, it is. I can't find the clause in the standard, but I'm only querying the 1997 draft, so that little detail may have been added later. However, Scott Meyers mentions it in Effective C++, in the item about operator new. (Item #8 2nd ed, Item #51 3rd ed)
    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

  5. #20
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by George2 View Post
    Hi cpjust,

    Is nothrow new supported in Visual Studio 2008?
    I haven't tried 2008, I'm still using 2005, but it's been in the C++ standard for a long time.

  6. #21
    Registered User
    Join Date
    Jan 2007
    Posts
    330
    yes, it could already be used in MSVC6, although new would always return NULL in that version. They do it correct nowadays including nothrow

  7. #22
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    Just to avoid starting a new thread on a related subject, I was wondering whether
    Code:
    std::vector<T> v;
    T *p = &v[0];
    triggers undefined behavior even if p is not dereferenced. I'm guessing that the allocation of the underlying array is done in a similar manner to new[] and that the answer is no, but want to be sure. (This isn't exactly what my code does, but it may use the expression &v[0] even when v has size 0, though it never dereferences anything it's not supposed to.)

  8. #23
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Yes, it's undefined behaviour. Namely, it's v[0] that triggers it. That's a dereference right there.

    Actually, with every sane standard library you'll get an assertion in debug mode.
    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

  9. #24
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    Oops, I should have realized that. Thanks.

    Edit: I've seen other code that does this:
    Code:
    T *p = v.empty()? 0 : &v[0];
    Now I know why.
    Last edited by robatino; 01-10-2008 at 04:38 PM.

  10. #25
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by robatino View Post
    Just to avoid starting a new thread on a related subject, I was wondering whether
    Code:
    std::vector<T> v;
    T *p = &v[0];
    triggers undefined behavior even if p is not dereferenced.
    That's undefined behavior even in straight C. Highly unlikely to cause a crash but still undefined.

  11. #26
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    Quote Originally Posted by brewbuck View Post
    That's undefined behavior even in straight C. Highly unlikely to cause a crash but still undefined.
    If v was a dynamic array (in C or C++), I would have just used "v" instead of "&v[0]" to sidestep the problem. I wanted to avoid dynamic arrays, but my program needs a huge number of small arrays, all of the same length (length 1 would be common), and the container overhead of a vector for each one is unnecessary, so I allocate a single huge vector and pass out pieces of the underlying array instead. So memory management can still be done vector-style but the container overhead amortizes to almost zero.

  12. #27
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Hi robatino,


    What do you mean "container overhead amortizes" and why it is zero?

    Quote Originally Posted by robatino View Post
    If v was a dynamic array (in C or C++), I would have just used "v" instead of "&v[0]" to sidestep the problem. I wanted to avoid dynamic arrays, but my program needs a huge number of small arrays, all of the same length (length 1 would be common), and the container overhead of a vector for each one is unnecessary, so I allocate a single huge vector and pass out pieces of the underlying array instead. So memory management can still be done vector-style but the container overhead amortizes to almost zero.

    regards,
    George

  13. #28
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Hi robatino,


    I still do not know why "triggers undefined behavior even if p is not dereferenced" after reading the discussion from you guys. Why it is undefined? Could you help to provide more description please?

    Quote Originally Posted by robatino View Post
    Oops, I should have realized that. Thanks.

    Edit: I've seen other code that does this:
    Code:
    T *p = v.empty()? 0 : &v[0];
    Now I know why.

    regards,
    George

  14. #29
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,632
    What do you mean "container overhead amortizes" and why it is zero?
    Generally, "amortize" means to reduce to some lower value in the long run. In this context, robatino was trying to emphasize that in the long run, the overhead of a single vector is spread out over the many logical partitions that make up the small arrays needed. If multiple vectors was used instead, each vector would have its own container overhead.

    I still do not know why "triggers undefined behavior even if p is not dereferenced" after reading the discussion from you guys. Why it is undefined? Could you help to provide more description please?
    As CornedBee pointed out, v[0] accesses an element that does not exist (since at that point the vector is empty). This results in undefined behaviour.

    By the way, kindly attempt to address the various other users in a single post. I find that drafting a post with a text editor is useful for posting long posts on message boards.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  15. #30
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    Thank you. I should also have mentioned that even if I allocated lots of little dynamic arrays, instead of vectors, there would still be per-object overhead, not to mention possible memory fragmentation. So it makes sense to allocate a single large container either way - and since the extra overhead of a huge vector vs. a huge dynamic array is negligible, it may as well be a vector.

Page 2 of 4 FirstFirst 1234 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