shedding light on pointers?
Author
Hi,
I was pondering about pointers in class today and this is my theory. Instead of using global variables to hold inventory items, score, etc., create a function that creates a pointer to a memory address that holds the inventory items and so forth. The only thing that has access to that memory is the function that creates the pointer(so that no worry of duplicate usages of a variable or memory address take place). Is the idea stated close to be correct?
In most contexts, the occurrence of a variable x in source means "take the current value of x when you reach this point at runtime". (The exceptions that come to mind are declarations and the left side of an assignment. And the & operator, of course.)
For example, if there is a function f(int a, int b) and someone calls f(x, y), then the current VALUES of x and y are passed to f, not the variables themselves. f has no way of knowing where those initial values came from. (The caller placed them on the stack for f to be consumed.) In particular, f doesn't know about the variables x and y.
There is absolutely no connection between the variables a, b and x, y. They are distinct variables which just happen to have the same values at the beginning of the function. Some people would say a and b are copies of x and y. If we change a or b inside the function, x and y cannot be affected by that.
If you think about it, it wouldn't even make sense to have those kinds of connections by default. Imagine someone calling f(2*x, y*y) or yet worse, ff(x+y, 5). What would you expect to happen to x and y if you changed a?
If you want a function that accepts variables themselves as input (and not just their current values at runtime), you must use pointers in C. "Hey function, please operate on a certain variable. I will tell you at runtime where this variable resides in memory so you can change its value."
For example, if there is a function f(int a, int b) and someone calls f(x, y), then the current VALUES of x and y are passed to f, not the variables themselves. f has no way of knowing where those initial values came from. (The caller placed them on the stack for f to be consumed.) In particular, f doesn't know about the variables x and y.
There is absolutely no connection between the variables a, b and x, y. They are distinct variables which just happen to have the same values at the beginning of the function. Some people would say a and b are copies of x and y. If we change a or b inside the function, x and y cannot be affected by that.
If you think about it, it wouldn't even make sense to have those kinds of connections by default. Imagine someone calling f(2*x, y*y) or yet worse, ff(x+y, 5). What would you expect to happen to x and y if you changed a?
If you want a function that accepts variables themselves as input (and not just their current values at runtime), you must use pointers in C. "Hey function, please operate on a certain variable. I will tell you at runtime where this variable resides in memory so you can change its value."
Quote:Original post by BlaDe16
Hi,
I was pondering about pointers in class today and this is my theory. Instead of using global variables to hold inventory items, score, etc., create a function that creates a pointer to a memory address that holds the inventory items and so forth. The only thing that has access to that memory is the function that creates the pointer(so that no worry of duplicate usages of a variable or memory address take place). Is the idea stated close to be correct?
Local variables - i.e. variables declared in a function such as you describe - fall out of scope once the function returns. Unless you declared them to be static, which prompts the compiler to essentially make them global. A static variable isn't truly global in the sense that other functions can access them. They maintain their state between calls to the function. Compilers typically group them in the same place in the executable file as other global variables (more or less - you should look into this further). Also note that static local variables are only accessible inside the function that calls them. That means that you can only operate on them with one function. That's not a good approach to dealing with items that you might want to operate on with different functions, such as inventory items and so forth.
Local variables fall out of scope once the function returns because they are put on the call stack. Subsequent function calls are likely to wipe them out. That is not good when working with pointers that you want to hang around between calls to functions, such as inventory items and so forth. It's ok to use a local variable as a pointer to memory that you allocated in a function, so long as you deallocate that memory before returning from the function, but that's not what you want with memory that you want to hang around between calls to functions, such as inventory items and so forth.
[Edited by - LessBread on October 23, 2008 2:35:44 PM]
Consider:
How would you feel if you lent me $5, and then when I paid you back, I didn't give you the same $5 bill that you originally gave me?
Now, how would you feel if you paid me to look after your cat for the weekend, and when you got back, there was a different cat in your living room?
Why the difference?
How would you feel if you lent me $5, and then when I paid you back, I didn't give you the same $5 bill that you originally gave me?
Now, how would you feel if you paid me to look after your cat for the weekend, and when you got back, there was a different cat in your living room?
Why the difference?
Quote:Original post by Zahlman
Why the difference?
Hm, it seems we need to distinguish between values and objects (the latter having values that can potentially change at runtime).
[Edited by - DevFred on October 23, 2008 3:18:55 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement