Note 5.4.1.
Depending on the diagram, the stack may grow up or down from main. The ones in Codelens grow down from
main.
Section 5.4 Stack Frames and Scope
Subsection 5.4.1 Stack Frames
When running the Codelens tool, it creates a diagram like this one:
This is known as a stack diagram, which shows the state of a program’s functions and variables. For each function there is a box, called a frame or stack frame, that contains the function’s parameters and variables.
The stack starts in the box for
main. I can see that at the point we were at in main, x and y have been set, but z has not been initialized yet. We have not initialized z yet, because the doubleValue function was called, and now it is executing. There is a stack frame for doubleValue right below main. It is highlighted in blue to indicate that it is where execution currently is.
As with other memory diagrams, stack diagrams show variables and functions at a particular point in time. If you go back and run the program again in Codelens, you will see the stack diagram change as the program runs.
Subsection 5.4.2 Scope
Stack diagrams help you to visualize the scope of a variable, which is the area of a program where a variable can be used. Only the values in the current stack frame are visible to the code that is running. In other words,
main can see x , y, and z, but not num or result. doubleValue can only see num and result.
If
main tries to directly use result, or doubleValue tries to directly use x, it is a compile error. The compiler will say that those variables are not defined. Which is true - they are not defined in that location, they are defined elsewhere and are out of scope where we are trying to use them. We call variables that are only visible in a particular function local variables.
This idea of scope helps enforce the abstraction of functions. The parameters and local variables in
doubleValue are not visible to main, and vice versa. This mean that the code in one place can’t directly affect the code in another. All the different parts can do is communicate via the clear channels provided by the parameters and return values.
It is possible for different stack frames to have variables with the same name. Below is a stack diagram for a program with three functions, all of which have a variable
x:
Note that the different
xs can have different values, like bar’s x and foo ’s x. Or they can have the same value, like main’s x and bar’s x. The three x’s are all different variables - you can not assume that they are related in any way. (You might know three people all named “John”. That does not mean they are all related. It is possible, but there is no reason to assume so.)
Insight 5.4.2.
It can help to think of there being two programmers involved in writing code involving a function. There is one programmer who writes the function. They don’t know anything about what is going on in the rest of the program. There is another programmer who is using the function. They don’t know anything about what happens inside the function (other than the information they are passing in and what should come back).
This is literally the case when you use a function from a library. You don’t know how
cos works and the person who wrote the function has no idea what programs you are going to use it in.
But even if you are the person who is writing and using the function, do your best to pretend there are two different “you”s — one working on the function and one who works on the rest of the code. Don’t assume that either you knows much about what they other is doing!
Checkpoint 5.4.1.
Subsection 5.4.3 Global Variables
There is one exception to the rule that variables are local to a function: global variables. These are variables that are defined outside of any function. They are visible to all functions in the program. Global variables are generally discouraged because they can make it difficult to understand how a program works. Imagine a program with 100 functions and 50 global variables. If you see a variable being used, you have to search through all 100 functions to see all the places it might be changed.
The one exception to the rule “avoid global variables” is for constants. Because we never have to worry about where a constant is being changed, it is considered OK to make constants be global. If you do, you can use them anywhere after that point.
Warning 5.4.3.
Using global variables to store information is considered a very bad idea in all but the most simple programs or in situations where all the other available options for solving the problem are an even worse idea. In the context of programs you write while using this book, there will never be a good reason to use global variables.
Checkpoint 5.4.2.
Why are we allowed to use the variable
x in both main and in the function definition of superSecretFunction?
int superSecretFunction(int n) {
int x = 0;
return (2 + (n * n) - 5 * n / 7) * x;
}
int main() {
int x = 1;
cout << "After using the super secret function, we get " << superSecretFunction (x);
}
- We’re using the same variable, but just reassigning the value from 0 to 1.
- We are actually using two different variables that happen to have the same name.
- Although the name of both variables is
x, they represent different locations in memory, and thus are different variables. - One
xis a local variable ofsuperSecretFunctionwhile the other is a local variable ofmain. - We can assign them different values but not the same value. Thus, if both were initialized to 0, then we’d get an error.
- Since they are not in the same storage location, they can store any value, including the same value.
- We’re not allowed to do this. The code will result in an error.
- The code does not produce an error.
You have attempted of activities on this page.
