Does editing objects by reference ensure that objects on the stack are not destroyed after the function returns?

I'm unable to understand the output of the following code

#include<iostream>
using namespace std;
template<typename T>
class foo{
    public:
        T a;
        foo(T b){
            this->a = b;
        }
        void print(){
            cout << a << endl;
        }
};
void goo(foo<int>& out){
    foo<int> a(10);
    out = a;
};
int main(){
    foo<int> a(5);    
    a.print();
    goo(a);
    a.print();
    return 0;
}
// Output: (C++17 g++-13)
// 5
// 10

I wanted to create a function which create a new object and returns a reference to it so that I can edit that object later for some other project. But I found out that returning references is not safe in C++. So I thought of making a void function which takes in as an argument a reference, I would create an object in the function and then edit the reference. This seems to work, but it shouldn't as the new object that gets created should be collapsed after the function returns and the reference should now be pointing to a non-allocated address. Accessing it should give a segmentation fault. But I'm not getting any such faults.

Assigning to a reference does not rebind the reference. You cannot rebind a reference. Assigning to a reference assigns to the original object.

> I wanted to create a function which create a new object and returns a reference to it so that I can edit that object later for some other project.

Thats not what your code does. And thats good. Because you cannot use a reference to a function local object after the function returned and the objec is gone. That would result in undefined behavior.

This is perhaps better understood by means of a simpler example. This is what your function does:

 void goo(int& a) {    // a is a reference to some int
    int x = 42;        // x is local to the function
    a = x;             // "some int" now equals 42
 }                     // x lifetime ends here !

What you are afraid of, but what your code is not doing is the following:

 int& broken_code() { 
    int x = 42;       // x is local to the function
    return x;         // return a reference to x
 }                    // x lifetime ends here !

Because x is local to the function, the reference returned is a dangling reference. It cannot be used without invoking undefined behavior.

In your code however, foo<int> a(5); in main is a foo<int> local to main. You do pass a reference to goo and assign something to that reference. This is equivalent to assigning directly to a. You do not return a reference from the function.

Last but not least...

> [...] Accessing it should give a segmentation fault.

Thats a misunderstanding. A common one, though a very dangerous one. Wrong code, code that has undefined behavior, is not guaranteed to crash. When your code has undefined behavior then literally anything is possible to happen. Expecting a crash is a dangerous misconception, because it makes you believe that either the code crashes or it is totally fine, which is generally wrong. To make sure your code is free of undefined behavior there are tools for static or runtime analysis, but eventually it is up to you to make sure that the code does what it should do.

When you are passing the object as reference you can edit the values stored at the address of object when it was created.
You are creating a new object in the function with value 10. It is created at another address but when you assign it to the referenced variable, it gets copied to it.
This is the case when you are using statically allocated memory, But in the case of dynamically allocated memory the new object's allocated memory would have deleted if you have copied it like normal variable. It is known as shallow copy.
In that case you would have to what is know as deep copy.

For more information you can refer Shallow Copy and Deep Copy in C++