bad_alloc

This is a discussion on bad_alloc within the C++ Programming forums, part of the General Programming Boards category; As for your example, your understanding of C++'s evaluation rules is wrong. When dealing with uninitialized variables, undefined behaviour is ...

  1. #46
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    As for your example, your understanding of C++'s evaluation rules is wrong. When dealing with uninitialized variables, undefined behaviour is triggered when the lvalue of the variable is converted to an rvalue. Since the address-of operator involves no such conversion, no undefined behaviour is triggered. See 4.1/1.

    The subexpression x merely gets the lvalue, which is a valid operation for uninitialized variables.
    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

  2. #47
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by CornedBee View Post
    As for your example, your understanding of C++'s evaluation rules is wrong. When dealing with uninitialized variables, undefined behaviour is triggered when the lvalue of the variable is converted to an rvalue. Since the address-of operator involves no such conversion, no undefined behaviour is triggered. See 4.1/1.

    The subexpression x merely gets the lvalue, which is a valid operation for uninitialized variables.
    Okay, good info.

  3. #48
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,717
    Yes, but the argument was that because v[0] is an undefined subexpression of &v[0] that therefore the entire expression &v[0] is undefined.
    I would rather use CornedBee's explanation: v[0] accesses an element that does not exist, possibly even causing a null pointer to be dereferenced. From then on we are dealing with undefined behaviour, so &v[0] can be considered as undefined. (What does it mean to take the address of an object that does not exist?)

    On the other hand, &x just takes the address of x. x exists and has an address, though its value has not yet been defined.
    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

  4. #49
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by laserlight View Post
    I would rather use CornedBee's explanation: v[0] accesses an element that does not exist, possibly even causing a null pointer to be dereferenced. From then on we are dealing with undefined behaviour, so &v[0] can be considered as undefined. (What does it mean to take the address of an object that does not exist?)
    I do understand the point here. I am curious to see if somebody can locate a platform where this does anything harmful (crash or otherwise):

    Code:
    std::vector<int> x;
    int *y = &x[0];
    In other words, a platform where converting a reference to a pointer is something more than a no-op.

    I submit that IN PRACTICE this operation is harmless.

  5. #50
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    How about Linux, X86-64, GCC 4.1?
    Code:
    #include <vector>
    #include <iostream>
    
    int main()
    {
      std::vector<int> v;
      std::cout << "Address of first: " << &v[0] << '\n';
    }
    Code:
    wasti@watson64 ~/forums $ g++ -D"_GLIBCXX_DEBUG=1" -o crash crash.cpp
    wasti@watson64 ~/forums $ ./crash
    /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/debug/vector:194:
        error: attempt to subscript container with out-of-bounds index 0, but
        container only holds 0 elements.
    
    Objects involved in the operation:
    sequence "this" @ 0x0x7fff46e9f940 {
      type = N15__gnu_debug_def6vectorIiSaIiEEE;
    }
    Aborted
    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 4 of 4 FirstFirst 1234
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