Thread: What's a stack?

You can think of a stack like a stack of plates. Each plate represents some sort of data element, from this category list:
1. The return address back to where the function was called.
2. The argument passed to a function.
3. A local variable within a function.

When you return from a function, all local variable plates and the plate with the return address is taken off the the stack. The return address plate is used to find the calling function so that execution can continue there. The calling function will remove the plates added to give the arguments to the function.

If we have the following code:

Code:

int main()
{
   func1(7, 8);
   return 0;
}

void func1(int x, int y)
{
    int d = 9;
    func2(y);
}

void func2(int a)
{
    int b = 11;
    ... do some stuff ... 
}

Inside func2, the stack will have:
b (with the value 11)
return address in func1.
a (with the value 8)
d (with the value 9)
return address to main
x (with the value 7)
y (with the value 8)
return address to C startup code.

When the return back from func2 to func1, the stuff down to a is removed, and inside func1, the argument a will be removed, and eventually, we return back to main and the
x, y arguments are cleared off the stack, and finally main will return to where it came from.

--
Mats

pursuant to what matsp wrote and "beginnerness": the structure of memory and the way it is literally used have given form to the language itself (and probably the language has influenced the construction of physical memory). So a lot of concepts get explained in relation to memory and the way it's managed. Two big central issues for me in learning and understanding have been:

1) allocation
2) reference and pointing

I think learning to use strtok is good here, because it helps to illustrate how a (possibly large) chunk of memory can be manipulated with pointers (the address the pointer points to is literally somewhere inside this contiguous chunk) AND the consequence (since the pointer is literally nothing, if you play with it you're really playing with a piece of the larger structure). Which is why we are warned:

"if a part of a program does not have as its purpose the modification of a certain data structure, then it is error-prone to modify the data structure temporarily."

Which I think means if you didn't want to change something permanently, you're better playing with a copy. That may be part of why we get a "stack" seperate from a "heap".

A stack is NECESSARY (at least for languages that wishes to support many levels of function calls [aka levels of nesting] and arbitrary number/type of parameters). In nearly all processors except the really tiny embedded processors, the stack is part of the processor architecture, and there is support to handle function calls in the instruction set, so a function call and the return from the function call translates directly into processor instructions, just like "+" becomes an add instruction, and "-"becomes a subtract instruction.

The heap, on the other hand, is not directly supported as such by the processor - it is just a lump of memory that an application can be asking for a chunk of.

The stack is also "automatically cleaning up", so when you go back from a function, the stack content is cleaned up (the compiler takes care of doing that), whilst the heap, the code needs to say "don't use this memory any more" in some way (usually by calling "free()" in C, and "delete" in C++).

And one thing to remember: Since data on the stack "disappears", it is invalid to pass back a reference to a stack variable to a calling function. Typically, this appears when someone writes code to return a local string variable.

Some languages have ONLY stack, such as the languages Forth and PostScript.

--
Mats