Guest User

Untitled

a guest
Jun 19th, 2018
83
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 3.14 KB | None | 0 0
  1. You can imagine the stack as being like a stack of plates. As soon as a function calls some other function things get added to the stack (from the bottom, upwards) starting with the return address (i.e. where the program flow should go back to, once the called function has finished).
  2.  
  3. Stack memory
  4. Let's suppose there was nothing on the stack to begin with. One of the functions (either the calling function or the called function) would start a stack by placing a return address - and some extra 'plates' might be added, representing any arguments that get passed to the called function (the called function's parameters).
  5.  
  6. Program execution then gets passed to the called function which probably adds some more plates in the form of 'local variables'. Every 'plate' has some sort of information written on it that means something special to te program. By the time the called function reaches its return statement it has a big stack of plates. Just before it returns, it removes the plates (one by one) from the top downward so that it can read the return address, written on that very bottom plate. The program then jumps back to that original return address.
  7.  
  8. The most important thing about the stack is that you don't need to think much about it. Your program manages it. Also, stack management is very efficient because the plates don't literally need to be removed (like they would if they were real plates). In reality, the program contains a "stack pointer" that simply gets updated each time a particular plate needs to be written to or read from. The size of the stack is usually quite small because it's mostly used for local variables (variables that go out of scope pretty soon after they're finished with). The size of the stack is set at compile time and is small enough to be available on any computer, no matter how little RAM it's got.
  9.  
  10. Heap memory
  11. The heap is a different thing altogether. Different PC's have different amounts of memory so it would be silly to have to allocate all the memory at compile time. If a particular computer has a lot of RAM, why not make use of it? Therefore the heap consists of memory that can be allocated at run time. The amount of heap memory is different for different machines and a well written program will take account of this (allocating heap memory sparingly - and not assuming that everyone will have massive amounts of it). Heap memory is most often used for 'large' things (e.g. the contents of a file) - or for things that need to 'stay around' in memory so that different functions can share the data (in other words, for NON-local variables). It's also used very frequently to allocate memory for things whose size is not known until run time. For example, if you had to open a file and read in the data, you don't know how much data exists until run time. In contrast, the size of objects allocated on the stack, needs to be known at compile time.
  12.  
  13. Whereas your program takes care of stack memory (allocating it & cleaning it up) it's the programmer's job to deal with heap memory. The size of objects allocated on the heap is often not known to the compiler - therefore the programmer must allocate and release the memory specifically.
Add Comment
Please, Sign In to add comment