What happens in C++ when I pass an object by reference and it goes out of scope?

Question

I think this question is best asked with a small code snippet I just wrote:

#include <iostream>

using namespace std;

class BasicClass
{
public:
    BasicClass()
    {
    }
    void print()
    {
        cout << "I'm printing" << endl;
    }
};

class FriendlyClass
{
public:
    FriendlyClass(BasicClass& myFriend) :
        _myFriend(myFriend)
    {
    }
    void printFriend()
    {
        cout << "Printing my friend: ";
        _myFriend.print();
    }
private:
    BasicClass& _myFriend;
};

int main(int argv, char** argc)
{
    FriendlyClass* fc;
    {
        BasicClass bc;
        fc = new FriendlyClass(bc);
        fc->printFriend();
    }
    fc->printFriend();
    delete fc;
    return 0;
}

The code compiles and runs fine using g++:

$ g++ test.cc -o test
$ ./test
Printing my friend: I'm printing
Printing my friend: I'm printing

However, this is not the behavior I was expecting. I was expecting some sort of failure on the second call to fc->printFriend(). Is my understanding of how the passing/storing by reference works incorrect or is this something that just happens to work on a small scale and would likely blow up in a more sophisticated application?

Don't you love it when we all shout "undefined behavior!" in unison? 8v) — Fred Larson, Sep 29 '11 at 22:01
"I was expecting some sort of failure on the second". Simply make print() virtual or store the text you're printing as an std::string member variable, and you'll get your failure. — SigTerm, Sep 29 '11 at 23:04
You generally don't want references as data members in C++. You are probably coming from a Java background. C++ references are nothing like Java references. If you want something like a Java reference, use a `std::shared_ptr` and create the object on the heap. — fredoverflow, Sep 30 '11 at 04:22
I've converted entirely to `unique_ptr`, `shared_ptr`, and `weak_ptr` in my code and I'm enjoying my lack of memory leaks :) — Corey D, Oct 12 '11 at 18:40

Matteo Italia · Accepted Answer · 2011-09-29T22:08:09.860

It works exactly as for pointers: using something (pointer/reference) that refers to an object that no longer exists is undefined behavior. It may appear to work but it can break at any time.

Warning: what follows is a quick explanation of why such method calls can seem to work in several occasions, just for informative purposes; when writing actual code you should rely only on what the standard says

As for the behavior you are observing: on most (all?) compilers method calls are implemented as function calls with a hidden this parameter that refers to the instance of the class on which the method is going to operate. But in your case, the this pointer isn't being used at all (the code in the function is not referring to any field, and there's no virtual dispatch), so the (now invalid) this pointer is not used and the call succeeds.

In other instances it may appear to work even if it's referring to an out-of-scope object because its memory hasn't been reused yet (although the destructor has already run, so the method will probably find the object in an inconsistent state).

Again, you shouldn't rely on this information, it's just to let you know why that call still works.

score 14 · Answer 2 · answered Sep 29 '11 at 21:59

14

When you store a reference to an object that has ended its lifetime, accessing it is undefined behavior. So anything can happen, it can work, it can fail, it can crash, and as it appears I like to say it can order a pizza.

answered Sep 29 '11 at 21:59

K-ballo

80,396
20
159
169

1

@R.MartinhoFernandes: That would be standards-conforming behavior! – Fred Larson Sep 29 '11 at 22:02
1

@R. Martinho Fernandes: Yes, but it does not have to. You cannot relay on that since its undefined behavior. – K-ballo Sep 29 '11 at 22:02
4

Never ever has any sort of undefined behaviour led to my getting a pizza, though. I just wanted to state this for the record. – Kerrek SB Sep 29 '11 at 23:47

score 1 · Answer 3 · answered Sep 29 '11 at 21:59

Undefined behavior. By definition you cannot make assumptions about what will happen when that code runs. The compiler may not be clearing out the memory where bc resides yet, but you can't count on it.

I actually fixed the same bug in a program at work once. When using Intel's compiler the variable which had gone out of scope had not been "cleaned up" yet, so the memory was still "valid" (but the behavior was undefined). Microsoft's compiler however cleaned it up more aggressively and the bug was obvious.

score 1 · Answer 4 · answered Sep 29 '11 at 21:59

1

You have a dangling reference, which results in undefined behavior.

answered Sep 29 '11 at 21:59

Fred Larson

60,987
18
112
174

score 1 · Answer 5 · edited May 23 '17 at 12:30

1

look here: Can a local variable's memory be accessed outside its scope?
It will almost will work, since you have no virtual functions, and you don't acces fields of BasicClass: all methods you call have static binding, and 'this' is never used, so you never actually access "not allocated memory".

edited May 23 '17 at 12:30

Community

1
1

answered Sep 29 '11 at 22:22

Ivan

1,103
2
10
15

What happens in C++ when I pass an object by reference and it goes out of scope?

5 Answers5

Linked

Related