bad_alloc

This is a discussion on bad_alloc within the C++ Programming forums, part of the General Programming Boards category; Thanks laserlight! Great reply. :-) Two more comments, 1. Originally Posted by laserlight Generally, "amortize" means to reduce to some ...

  1. #31
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks laserlight!


    Great reply. :-)

    Two more comments,

    1.

    Quote Originally Posted by laserlight View Post
    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 can understand the overhead of maintaining multiple container compared with one container. But I am not sure what do you mean "some lower value"? Confused. What are the so called lower value do you mean? :-)

    2.

    Quote Originally Posted by laserlight View Post
    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.
    I can understand that accessing v[0] is undefined behavior since v[0] does not exist for an empty vector.

    What do you understand is why as you guys mentioned before "triggers undefined behavior even if p is not dereferenced" in the following code segment. I think it should be ok (not undefined behavior) if p is not dereferenced. :-)

    Please feel free to correct me if I am wrong. :-)

    Code:
    std::vector<T> v;
    T *p = &v[0];

    have a good weekend,
    George

  2. #32
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,650
    I can understand the overhead of maintaining multiple container compared with one container. But I am not sure what do you mean "some lower value"? Confused. What are the so called lower value do you mean? :-)
    In this case, zero, or perhaps "nothing".

    What do you understand is why as you guys mentioned before "triggers undefined behavior even if p is not dereferenced" in the following code segment. I think it should be ok (not undefined behavior) if p is not dereferenced. :-)
    p does not matter at all, since the undefined behaviour lies with v[0].
    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

  3. #33
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks laserlight,


    You mean in the following code, using p is ok but using *p is not ok? :-)

    Code:
    std::vector<T> v;
    T *p = &v[0];
    Quote Originally Posted by laserlight View Post

    p does not matter at all, since the undefined behaviour lies with v[0].

    regards,
    George

  4. #34
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,650
    You mean in the following code, using p is ok but using *p is not ok? :-)
    You have been told multiple times: that piece of code is simply wrong.
    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

  5. #35
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Sorry laserlight,


    What makes me confused before is your point and robatino's point are different.

    1.

    This is what robatino mentioend, seems using p and *p (dereferencing) are both incorrect.

    Quote Originally Posted by robatino View Post
    Code:
    std::vector<T> v;
    T *p = &v[0];
    triggers undefined behavior even if p is not dereferenced.
    2.

    This is what you mentioned before, seems you mean using p is ok, but using *p is not ok.

    Quote Originally Posted by laserlight View Post
    p does not matter at all
    Hope I clarifies what makes me confused before. :-)

    Quote Originally Posted by laserlight View Post
    You have been told multiple times: that piece of code is simply wrong.

    regards,
    George

  6. #36
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,650
    This is what you mentioned before, seems you mean using p is ok, but using *p is not ok.
    Basically, this is a question of emphasis. Let's change the code to:
    Code:
    T *p = 0;
    So now, using p is indeed okay, but using *p is not okay.

    But what are we to make of:
    Code:
    std::vector<T> v;
    T *p = &v[0];
    We could say that using p and *p is both not okay, or we could relate it to my example above and say that using p is okay but *p is not okay, but that's besides the point. The point is that &v[0] is not okay, so whether using p is okay or using *p is okay does not matter any more.
    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

  7. #37
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks laserlight,


    I think my question is answered. Thanks again for your patience. :-)

    Let me do a brief summarize. I think the code,

    Code:
    T *p = 0;
    is ok because of p points to valid address (even NULL address), so using p is ok.

    But for the code,

    Code:
    std::vector<T> v;
    T *p = &v[0];
    it is not ok since &v[0] is not valid (no elements, including 1st element exists in vector v), and p is pointing to an invalid address &v[0], using p is not valid, and using *P is even not valid. :-)

    My summary correct?

    Quote Originally Posted by laserlight View Post
    Basically, this is a question of emphasis. Let's change the code to:
    Code:
    T *p = 0;
    So now, using p is indeed okay, but using *p is not okay.

    But what are we to make of:
    Code:
    std::vector<T> v;
    T *p = &v[0];
    We could say that using p and *p is both not okay, or we could relate it to my example above and say that using p is okay but *p is not okay, but that's besides the point. The point is that &v[0] is not okay, so whether using p is okay or using *p is okay does not matter any more.

    regards,
    George

  8. #38
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    Since the expression v[0] itself triggers undefined behavior (which I should have realized originally), anything the program does after that is irrelevant - the program could crash before it even gets a chance to try evaluating &v[0], much less assigning it to p.

  9. #39
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks for your clarification, robatino!


    Quote Originally Posted by robatino View Post
    Since the expression v[0] itself triggers undefined behavior (which I should have realized originally), anything the program does after that is irrelevant - the program could crash before it even gets a chance to try evaluating &v[0], much less assigning it to p.

    regards,
    George

  10. #40
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by robatino View Post
    Since the expression v[0] itself triggers undefined behavior (which I should have realized originally), anything the program does after that is irrelevant - the program could crash before it even gets a chance to try evaluating &v[0], much less assigning it to p.
    The evaluation of &v[0] does not involve evaluating v[0].

  11. #41
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Yes, it does. Especially for an overloaded [].

    In practice, it does not for built-in pointer []. However, in standard theory it does, and thus the program behaviour is undefined, because whatever optimizations the compiler makes, the program must still adhere to the standard.
    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

  12. #42
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Why brewbuck?


    Any more description of the internal process of evaluation of &v[0] and evaluation of v[0], so that we can see your points of the different process. :-)

    Quote Originally Posted by brewbuck View Post
    The evaluation of &v[0] does not involve evaluating v[0].

    regards,
    George

  13. #43
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by CornedBee View Post
    Yes, it does. Especially for an overloaded [].
    Even in that case, operator[] returns a reference, not a value, which still doesn't involve actually evaluating anything. I understand the standard says it's undefined.

    It is not the case that all sub-expressions of an expression must have defined values. If that were the case, the following program would be undefined:

    Code:
    void clear_integer(int *x)
    {
        *x = 0;
    }
    
    int main()
    {
        int x;
    
        clear_integer(&x);
        return 0;
    }
    I don't think anybody will dispute the validity of this code. But 'x' does appear as a subexpression in the call to clear_integer(). At the time of the call, it is uninitialized. The "evaluation" of this uninitialized value should trigger undefined behavior according to the above, but I think we all agree that it doesn't. What gets passed is the address of x, not the contents of x.

  14. #44
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,650
    The "evaluation" of this uninitialized value should trigger undefined behavior according to the above, but I think we all agree that it doesn't. What gets passed is the address of x, not the contents of x.
    Only one operator is at work here: the address of operator&. But two operators are at work for &v[0].
    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. #45
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by laserlight View Post
    Only one operator is at work here: the address of operator&. But two operators are at work for &v[0].
    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.

    In my example, x is an uninitialized subexpression of &x and therefore... The entire expression &x is undefined? So this means we can't take the address of uninitialized variables?

    Honestly I'm not sure exactly what the standard claims here.

Page 3 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