why is this still working??

Discussion in 'C++' started by Hans Van den Eynden, Oct 20, 2004.

  1. This is my code:

    int& dangling_reference();

    int main(int argc, char *argv[])
    Integer *a = new Integer(4);
    Integer *b;
    delete a;

    //dangling reference 1
    cout<<"a: "<<a->integer<<"b: "<<b->integer<<endl;

    // dangling reference 2
    int x=dangling_reference();
    cout<<"int x: "<<x;


    int& dangling_reference() {
    int x=3;
    return x;

    Why don't I get an error and why are the values of a->integer en x correct??
    It's this a dangling reference fault??

    bizar i think
    Hans Van den Eynden, Oct 20, 2004
    1. Advertisements

  2. Hans Van den Eynden

    Andre Kostur Guest

    (Hans Van den Eynden) wrote in
    [snip standard example of returning a reference to a local variable]
    This invokes what's called "Undefined Behaviour". The compiler/computer is
    free to do whatever it wishes, including continuing to run as if there is
    no problem (or alternately, make the appropriate calls to your video card
    to attempt to drive your monitor at 2.4 GHz horizontal refresh rate,
    causing your monitor to explode).
    Andre Kostur, Oct 20, 2004
    1. Advertisements

  3. Hans Van den Eynden

    Heinz Ozwirk Guest

    Not bizar - just undefined.

    Heinz Ozwirk, Oct 20, 2004
  4. Most likely cause nothing messes with the location on the stack where
    x is stored.
    =?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?=, Oct 20, 2004
  5. WTF is 'Integer'?
    That's not a dangling reference. That's accessing members of
    an object whose lifetime has ended. Undefined behaviour occurs.
    What error would you like to get? The behaviour is undefined. Your
    implementation may (has all rights to) create the code that will give
    you some kind of error. Or it may (has all rights to) create the code
    that will format the hard drive of your computer. The Standard makes
    no requirement here.
    No, it's your fault. You wrote the code that has undefined behaviour.

    Victor Bazarov, Oct 20, 2004
  6. Hans Van den Eynden

    Ron Natalie Guest

    There's no such thing as a "dangling reference fault." Both cases are
    undefined behavior. There is no requirement that the compiler detect
    or otherwise have any specific behavior when you break the rules like
    Ron Natalie, Oct 20, 2004
  7. Hans Van den Eynden

    JKop Guest

    Just for clarity: Both the pointers "a" and "b" point to an object which no
    longer exists.

    Undefined Behaviour.

    Here your copy constructing an object of type "int" from an object which no
    longer exists.

    Undefined Behaviour.

    Your program is not ill-formed, though it does produce undefined behaviour.

    If you were to run it on WinXP, you'd probably get a runtime error for
    accessing memory that isn't yours.

    JKop, Oct 21, 2004
  8. Actually, in WinXP you will get undefined behavior, too. If you're (still)
    lucky, it might work. The deallocated memory is still reserved by the
    process (and might still contain the object state before delete, if it
    wasn't overwritten by other allocations).

    Catalin Pitis, Oct 21, 2004
  9. Other way round:
    If you are lucky, it crashes immediatly.
    If it appears wo work, you were unlucky. Unlucky in the sense
    that it seems to work in your test environment, while it immediatly
    crashes when your customer tries the program the first time leading
    him to believe you made a bad job (which you did) and thus he refuses
    to pay your bill.
    Karl Heinz Buchegger, Oct 21, 2004
  10. You're right. I was too optimistic :).
    Sorry for that :)
    Catalin Pitis, Oct 21, 2004
  11. Hans Van den Eynden

    JKop Guest

    That's the compiler's job!

    JKop, Oct 21, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.