Why does this pointer behave differently between g++ and visual studio 2022's compiler?

Question

Edit: my question was relating to the difference between compilers but I was just mislead to think there was different behavior when really both compilers were showing the expected "undefined behavior"

I know that using the static keyword here would be good for the building_num integer, but I don't understand why the value prints correctly when compiling with g++, I would think the integer value should be erased after the assign_building_num function terminates

With visual studio's compiler I see the behavior I assume, where it doesn't print out 400, it prints out some random number (in this case it is always 32759 for some reason)

#include <iostream>
#include <string>

using namespace std;

class building {
    int* ptr_building_num;

public:
    void set_building_num(int* num_ptr) {
        ptr_building_num = num_ptr;
    }

    void print_building() {
        cout << *ptr_building_num << flush;
    }
};

void assign_building_num(building* building_ptr) {
    //int* ptr_to_building_num = nullptr;
    int building_num = 400;
    int* ptr_to_building_num = &building_num;

    building_ptr->set_building_num(ptr_to_building_num);
}

int main() {
    building* ptr_to_some_building = nullptr;
    ptr_to_some_building = new building;

    assign_building_num(ptr_to_some_building);

    ptr_to_some_building->print_building();

    return 0;
}

Answer 1

Variables declared in a scope (in this case, the scope for building_num is the body of the function assign_ building_num) cease to exist once the scope exits.

You are taking the address of an integer that only has a short lifetime, and retaining its address after the object has been destroyed.

Reading from a pointer to a destroyed object is Undefined Behavior, so both compilers are correct.

The integer whose address that your building object holds must live at least as long as the building object itself.

EDIT: Since a question Undefined Behavior came up, here's what cppreference says about it, for completeness:

undefined behavior - there are no restrictions on the behavior of the program. Examples of undefined behavior are data races, memory accesses outside of array bounds, signed integer overflow, null pointer dereference, more than one modifications of the same scalar in an expression without any intermediate sequence point (until C++11)that is unsequenced (since C++11), access to an object through a pointer of a different type, etc. Compilers are not required to diagnose undefined behavior (although many simple situations are diagnosed), and the compiled program is not required to do anything meaningful.

Answer 2

You have made some very , very convoluted code that ends up setting 'building.ptr_building_num' to point at

   void assign_building_num(building* building_ptr) {
    //int* ptr_to_building_num = nullptr;
       int building_num = 400;              <<<<===== this value here
    int* ptr_to_building_num = &building_num;

    building_ptr->set_building_num(ptr_to_building_num);
}

THats not valid. Because that variable will disappear once that function ends. Normally VS or GCC would warn you about this but you have done enough juggling that they cant see that you are doing that.

Why does it work sometimes and not others. becuase you have invoked Undefined Behavior, the result can be anything. On my VS system I got 400.

But if I change the code to

assign_building_num(ptr_to_some_building);

cout << "test test\n"; <<== add this

ptr_to_some_building->print_building();

then I get

test test
-858993460

Its not clear what you actually want to do. If you want building to point to an integer (why?) then you need to allocate that integer somewhere stable.

You hint at 'static' , this will certainly work

void assign_building_num(building* building_ptr) {
    //int* ptr_to_building_num = nullptr;
    static int building_num = 400; <<<=======================
    int* ptr_to_building_num = &building_num;

    building_ptr->set_building_num(ptr_to_building_num);
}

but is a very odd thing to do, all building instances will end up pointing to the same integer. Maybe thats what you want. Hard to say. Otherwise allocate on the heap. Or if it just one integer put it in the building object