So what's really going on inside of memory.
scope (作用域）
This rectangle is let's say R RAM, the memory inside of your computer. This is different from the hard disk, which is where files and stuff are permanently stored.
RAM is this memory used for ephemeral purposes.
When you double-click a program, it's loaded into RAM. When you're working on a file, it's saving constantly to RAM but also hopefully to disc, to the hard disk so you don't actually lose it if the power goes off.
Well, if this is now my RAM:
what's really happening is some organization to functions in such being called, by default, if this is my RAM, main excel can have parameters, as we'll see in just a moment.
Arg C and Arg V, those symbols I've been waving my hands at, well where are they located in memory?
Well, memory is this rectangle, by default, they're located at the bottom. Now they may not take up the whole width. This is somewhat of a artist's rendition, but they're the very bottom of my RAM.
Now, what's on top of that? ( chart above)
Well, if main has any local variables X or Y or temp or foo or bar, or whatever the case may be, those variables come next in memory.
So you can think of it as left or right, top to bottom, or whatever, the point is they come next in RAM.
Now if you call a function, like increment or cube or swap, or in this case, foo, those variables are the parameters to that function, end up getting stored next in memory.
So everything is literally going back to back to back and so foo, similarly, if you have any local variables, like temp, it then goes here(right side). So when I said earlier that as soon as swap returns, all of the memory allocated for swap is now useless. It just disappears.
That's because this process on roles.
If you think of these kind of like trays in a cafeteria, right, that are kind of upside down, and by default, they're stacked from the floor on up and up and up.
Well, if you want to call a function, it's like putting another tray on that stack of trays and that tray represents a chunk of memory that that function can use.
Well, if that function calls another function, you put another tray on, and so that new tray represents that function's chunk of memory.
But as soon as the most recently called function finishes executing, you have to take that tray off the stack in order to get at the previous function's memory, and once he's done executing, you have to take that one off and then what's left well then main.
So even though we're not literally throwing RAM away, we're not physically moving anything, conceptually, we have to go through memory in this order back to back to back and then undo it.
So pictorially, you can imagine foo getting called and then it finishes running; so these rows in this chart will just be whisked away.
The bits are still there, muck like bits are still left when you erase a file on your hard disk but they're forgotten about.
So pictorially, this row would simply disappear.
Now, there's a bigger picture here:
I intentionally used this very common analogy of a stack of trays in a cafeteria.
Well, because the memory we've been using for local variables, and for functions, storage space is what computer scientists generally call the stack.
It turns out that slightly before the stack, slightly before this conceptual chunk of memory, there's other things called environment variables that we may see over time but elsewhere in memory are other things.
Text is where the zeros and ones that compose your actually stored. So when you compile a program called A.out, or skittles or whatever, and you double-click that program, or in our command line environment, run it with dot slash(./) skittles, that program is loaded into memory just like Microsoft Word or whatever would be on your own computer.
Where is it put in memory? Conceptually, it's put at the top of my chunk of RAM, below it, goes initialized and uninitialized data -- this is a fancy way of saying global variables come next -- and below that, comes what's called the heap.
So before long(不久之后), we'll see, especially for problems , that we can't allocate an int every time we want to store something, because what if we want to store 140,000 English words. Right. We're not going to have 140,000 variables in my program. I need access to more memory, and I need it fast. Well, there's a chunk of memory called the heap that you can grab as much memory as you want so long as it exists for your program.
But there's kind of a problem here. And this picture kind of makes clear that we're headed for disaster.
There's only a finite amount of memory. And very deliberately has that memory been laid out as such.
So what's the problem? We're probably going to run into very soon. Right, stack.
stack, stack, stack. You're calling functions, functions, functions, but you're allocating heap, heap, heap memory for your words.
Eventually, stack and heap will collide(冲突).
And one of the ways you can make a program crash, intentionally or not, is to essentially use up too much memory or call too many functions and what happens is, bam(崩掉), one hits the other and bad things happen.
