-
pointers and variables
Ok, I am not exactly new to programming. While Ive done alot of relatively few programs (you could say ive spent the last 8 years learning the basics of basic, c, cobol, c++, java, html, cold fusion, and sql) but nothing realy advanced beyond the point of simple calculator programs and pure text data input/output. (I might say ive done a bit further than that with cold fusion/sql stuff. e.g.: linked tree node structures to handle database lists for an outline program, but almost not real programming was involved).
Well, im starting to get more serious with my programming, so ive been looking over pointers and arrays last few days and I came to a question I couldn't seem to answer with the couple c books ive got.
Whereas a variable is basicaly an address with something in it. lvalue being the memory address in which the rvalue is, rvalue being the actual "data". Isnt there also something more? Like a third value which is the name of the variable? So in reality we have two slots in memory being used with the name and the data? How much actual space in memory is being used if say the type is an int?
A pointer then would be a space in memory that holds its name and a memory address. That address potentialy pointing to "data". How much actual space in memory is being used if the type is an int? (not including the space in memory the address would be pointing to)
My third question is with arrays. Im not quite sure how to explain how I think arrays work (in memory wise) but I am still insterested how much total memory would be taken by an int array[1]; If anyone can explain it better than me (me having not explained at all), please do so.
I may not have gotten it right. While I can use arrays, pointers, and obviously variables, I want to know how exactly they work and how much real memory they take not just the "2 bytes" an int variable seems to imply.
-dharh
-
How much a variable takes is generally implementation-dependent, but here goes...
The variable name is scrapped by your compiler. It just takes the names, does some math, and instead of using the variable names, it hard-codes the addresses that pertain to each variable in the code. This is why there isn't any way to refer to a variable called num1, by using a string, "num1".
The address of the variable isn't technically stored in memory either, although it is stored in the code... it's kinda like this... and asking how much memory does the '2' take? The '2' is not stored anywhere but in the code itself, so we say that is takes no memory. The same goes for the pointer that is i.
So the only memory that a variable really takes is that of the memory it refers to. The name of the variable isn't used by the program, and the address itself isn't stored anywhere, it's written into the code. sizeof(x) will tell you how much memory the value x refers to.
Similarly, pointers hold the information needed to refer to a variable... pointers are basically just glorified versions of the unsigned long, since all you need to refer to a variable is it's memory address. Again, if x is a pointer, then sizeof (x) will accurately describe how much memory that refers to.
Arrays are hardcoded pointers. The pointer value for the array doesn't take any memory. Just the memory that is reserved by the array gets stored in memory. So... if x is an array, then sizeof (x) will accurately describe all the memory that array takes (which is, the space reserved for the values it is intended to hold).
All in all, variable names are not stored in memory or the code of your program at all (except for debugging purposes). The addresses of variables are in the code, but they're hardcoded, and don't take any memory themselves. Only the data referred to by the variable actually takes any memory.
If you really want to get a grip on the idea of the details of how programs work, you probably should try some elementary assembly, although it's somewhat difficult to find any resources for that.
-
Here is the simple answer-- You are confusing the language (it's grammar and syntax) with the executable code.
Here's the full answer--
Variables are only so _you_ can understand what you're referencing when writing in a language known as C. The compiler is your translator. As such, it accepts your human understandable gibberish (C) and builds tables to allow it to resolve "links".
Let's give you a real-world example--
You have a function main(). Inside main, you have a variable named "ball" that is a long. Where does it goes, how does it remember what/where "ball" is?
Like this:
When the compiler sees main(), it determines that the function main() will load at a specific location within the application heap-zone in RAM. For our intents and purposes, we will arbitrarily say that the location is:
Main(): 0x000AC142
It then resolves that each of the variables allocated within main, will set in RAM "on the stack". A stack is a trail of breadcrumbs that the CPU leaves behind to tell it where it's at, and where it's been. As more code executes (more and more functions get called), the trail gets longer. As functions return, the trail is shortened.
Since "ball" is a long, only 4-bytes are allocated on the stack. When the CPU actually references this variable, will reference it based on the address in RAM where main() starts, _minus_ an offset to get onto the stackframe allocated for main()'s local variables.
So, whenever main references "ball" instead of having a 'variable name', somewhere, it will instead access it by saying something like:
0x000AC142-0x12.
Every occurrence of "ball" in main() in your sourcecode, gets changed to the actual addressing minus the offset. Which means that that a variable and a pointer are identical in their storage and access methods to the computer. It's just that with a pointer, you "go through" (called 'indirect access') the contents of the variable (which is an address) to get elsewhere.
To give you on the last sentence, look at "ball" this way, as both a variable and a pointer:
Code:
long ball;
ball = 5;
"ball" is stored at location 0x000AC142 (MAIN)minus an o
-
Completed Post
Here is the simple answer-- You are confusing the language (it's grammar and syntax) with the executable code.
Here's the full answer--
Variables are only so _you_ can understand what you're referencing when writing in a language known as C. The compiler is your translator. As such, it accepts your human understandable gibberish (C) and builds tables to allow it to resolve "links".
Let's give you a real-world example--
You have a function main(). Inside main, you have a variable named "ball" that is a long. Where does it goes, how does it remember what/where "ball" is?
Like this:
When the compiler sees main(), it determines that the function main() will load at a specific location within the application heap-zone in RAM. For our intents and purposes, we will arbitrarily say that the location is:
Main(): 0x000AC142
It then resolves that each of the variables allocated within main, will set in RAM "on the stack". A stack is a trail of breadcrumbs that the CPU leaves behind to tell it where it's at, and where it's been. As more code executes (more and more functions get called), the trail gets longer. As functions return, the trail is shortened.
Since "ball" is a long, only 4-bytes are allocated on the stack. When the CPU actually references this variable, will reference it based on the address in RAM where main() starts, _minus_ an offset to get onto the stackframe allocated for main()'s local variables.
So, whenever main references "ball" instead of having a 'variable name', somewhere, it will instead access it by saying something like:
0x000AC142-0x12.
Every occurrence of "ball" in main() in your sourcecode, gets changed to the actual addressing minus the offset. Which means that that a variable and a pointer are identical in their storage and access methods to the computer. It's just that with a pointer, you "go through" (called 'indirect access') the contents of the variable (which is an address) to get elsewhere.
To give you on the last sentence, look at "ball" this way, as both a variable and a pointer:
Code:
long ball;
ball = 5;
"ball" is stored at location 0x000AC142 (MAIN) minus an offset of 0x12. So "ball" is stored at location: 0x000AC130.
In RAM, ad "ball"'s location, we see:
000AC130 00 00 00 05 A3 59 6B DD
Only the first 4-bytes count (a long word), so 0x00000005 is what is stored there.
That's a variable.
---
Now, what if "ball" were a pointer? Let's try this:
Code:
long *ball;
ball = (long*)0x0004F7E2;
Again, if we reference "ball" on the stack at location 0x000AC130, what do we find? Why we find
000AC130 00 04 F7 E2 A3 59 6B DD
of course!
So when you access it using the '*' you actually so, "get the contents of "ball", which is 0x0004F7E2, and "go through" that as another address".
What we see at location 0x0004F7E2 is the following:
0004F7E2 00 09 3F AA 0D 00 00 01
which is: 0x00093FAA or 606122 decimal.
Enjoy.
-
My apologies for the incomplete post, my granddaughter interrupted me and knocked my keyboard off the table. I don't believe she'll wreak such havoc in the future. The cane leaves such lovely red weals.
