3 replies to this topic

[Khaiy]

I'm trying to figure out if a problem that I had last night is potentially a scope issue or not. I have a Game object which has a field called currentScreen. currentScreen is a variable of type Screen. Game also has a method called ChangeScreen(Screen nextScreen), which has a single line of code assigning nextScreen to the currentScreen field.

When the Game object is constructed a pre-defined Screen object called TestScreen is assigned to the currentScreen field. TestScreen has a method that generates a new screen like this, where Popup is descended from Screen just as TestScreen is:

private void GeneratePopupScreen(){	Game.ChangeScreen(Popup p = new Popup());}

When this code executes, what lifespan will p have? It's declared and instantiated inside of a method, so it seems like it should have local scope and go out of scope as soon as the GeneratePopupScreen methods ends, which is immediately after the ChangeScreen method ends. But because memory is explicitly allocated on the heap via the new operator, and a reference independent of the GeneratePopupScreen method is assigned p's memory address immediately upon p being instantiated it also seems like maybe p could persist after GeneratePopupScreen ends.

Will p go out of scope once GeneratePopupScreen terminates?

[Oberon_Command]

But because memory is explicitly allocated on the heap via the new operator, and a reference independent of the GeneratePopupScreen method is assigned p's memory address immediately upon p being instantiated it also seems like maybe p could persist after GeneratePopupScreen ends.

Correct.

Will p go out of scope once GeneratePopupScreen terminates?

Yes, because p is just a (nullable) reference; p isn't the object. The reference might go out of scope, but the actual object to which it's initialized will persist until the next garbage collection run, or longer if Game.ChangeScreen does something meaningful with it (like push a reference to it on a state stack, for instance), since an object is not considered "dead" until there are no more references to it.

For reference types, lexical scope does not constrain object lifespan.

[Kylotan]

But because memory is explicitly allocated on the heap via the new operator, and a reference independent of the GeneratePopupScreen method is assigned p's memory address immediately upon p being instantiated it also seems like maybe p could persist after GeneratePopupScreen ends.

 

Assuming C++, Java or C#: memory doesn't hold on to variables - variables maintain a reference to bits of memory.

 

In C++, if the variable goes out of scope then you've just lost the reference and the memory stays there, allocated but inaccessible. The 'exception' is when the variable is actually an object which may perform some cleanup of memory it owns. In C# and Java, the memory gets deallocated once it realises that nothing refers to it - ie. some time shortly after p goes out of scope.

 

But in no situation in any language I know of could the name 'p' continue to exist outside of that function. The name itself only has that limited scope.

 

It's important to have a good mental model of the difference between the scope of the identifier (in this case p), the value the identifier refers to (in this case, a specific instance of Popup), and the lifetime of the memory allocated for the object (ie. a bit of the heap that contains the instance of Popup).

Edited by Kylotan, 13 March 2013 - 11:25 AM.
language confusion

[Khaiy]

Thank you both for the replies. Although that means I've got a lot more debugging ahead of me tonight...