the stack?

Started by
16 comments, last by Spoonbender 18 years, 9 months ago
Quote:Original post by redirectionkid
Okay, I think I have a better idea of things. However I'm not quite sure here:

Quote:Original post by Spoonbender
Every new function pushes data onto the stack, and when the function ends, they're popped off, leaving the stack as it looked before the function was called.


Do all variables within the function utilize the stack by default? If so, how could one access a variable that is defined before another variable, without "popping off" the previous variable, and losing that data?

Well, that's where the similarity to a real-world stack ends. On a computer, it's just a bunch of memory addresses. If you have the address of something halfway down the stack, then you can manipulate it. The stack is just a method to be able to keep adding and removing data, always in a "first in-last out" order.

If a function is called with the address of another variable on the stack, then it won't be on top of the stack, but you have the address, so you can still read it or change its value.

On the other hand, when a function ends, all its data is popped off the stack, meaning that if you still have the address of a function variable (maybe you returned the address of a local variable?), then suddenly that points to nothing, to a semi-random value that's going to be overwritten as soon as someone push data onto the stack.

That's why you use 'new' to allocate memory. When you use new, you create a variable on the heap. It stays there until it's deleted.

When you just do something like this:

int x = 42;
it's created on the stack, and once the function ends, poof, the variable is gone.

Make sense? :P

Or to put it in code, imagine you call a function like this one:
int* foo(int* a){  // Now a points to something further down the stack (or maybe on the heap).  // If it's on the stack, it won't be popped off until the function it exists  // in ends, so it's safe enough to use here.  // Create a local variable and return the address of it.  // Of course, this goes out of scope when the function ends, so returning  // the address of it is *very* stupid. What happens is that when the function   // ends, it pops all the local variables (the ones created in this function   // without using 'new') off the stack, and suddenly, &b points to nothing in  // particular. It'll get overwritten any moment.  int b = 1;  return &b;}
Advertisement
Quote:Do all variables within the function utilize the stack by default? If so, how could one access a variable that is defined before another variable, without "popping off" the previous variable, and losing that data?

Or perhaps the stack only applies to constants? Nilkn mentioned something about the heap, and static/dynamic data... is this what he/she is referring to?


As said before 'ONLY' when you use malloc, calloc and new you are allocating memory on the HEAP. Local variables are stored on the Stack.

elements on the Stack can be addressed by index from the start of the frame; a frame contains variables bound to a scope or by using real addresses (not recommended as you can and might access data that does not exist or does not belong to you)

Reread my prevous answer...

Cheers
Okay so basicly you're saying that if you have an external pointer pointing to a variable that is local to a function, and that function terminates, the address of the actual variable is deleted, and thus your pointer would be pointing to some random location... all because that variable was stored on the stack.

But-

By using "new" you allocate space for a variable on the heap, where the variable will remain in the same location until "delete" is used, despite the life of the function with which the variable resides in.

Is that correct?

[EDIT: Well I guess it would be better to say that the value is deleted, not the address... so you're still pointing to the same address, just a random value that could change at any moment. Right?]
Quote:Original post by redirectionkid
Do all variables within the function utilize the stack by default? If so, how could one access a variable that is defined before another variable, without "popping off" the previous variable, and losing that data?

If you're talking about two variables in the same function, one defined before the other, then a pointer to the base of the stack is stored.

Positive offsets from this base pointer are parameters or arguments passed to the function, already on the stack. Then the function's variables are pushed on the stack. These variables are accessed at negative offsets from the base pointer, so they don't actually have to be popped off the stack to be accessed.

Quote:Original post by redirectionkid
By using "new" you allocate space for a variable on the heap, where the variable will remain in the same location until "delete" is used, despite the life of the function with which the variable resides in.

Is that correct?

Yes.
Ra
Quote:Original post by redirectionkid
Okay so basicly you're saying that if you have an external pointer pointing to a variable that is local to a function, and that function terminates, the address of the actual variable is deleted, and thus your pointer would be pointing to some random location... all because that variable was stored on the stack.

Pretty much. Of course, the address isn't deleted, but the place it points to is no longer reserved for that variable, so it might get overwritten any moment (or it might have been already)


Quote:
By using "new" you allocate space for a variable on the heap, where the variable will remain in the same location until "delete" is used, despite the life of the function with which the variable resides in.

Yup.

You can try it for yourself.
Have a main function that calls first a function which returns the address of a local variable, and afterwards, call another function which is passed that address. Then try to read it. If the latter function takes up enough space on the stack, it'll overwrite the value, and if you try to print out the old variable then, you'll get some new garbage value.
Quote:Original post by Spoonbender
Quote:Original post by redirectionkid
Okay, I think I have a better idea of things. However I'm not quite sure here:

Quote:Original post by Spoonbender
Every new function pushes data onto the stack, and when the function ends, they're popped off, leaving the stack as it looked before the function was called.


Do all variables within the function utilize the stack by default? If so, how could one access a variable that is defined before another variable, without "popping off" the previous variable, and losing that data?

Ah, sounds like you've got it. :)

That's why you use 'new' to allocate memory. When you use new, you create a variable on the heap. It stays there until it's deleted.


I don't think you're following his question.

To the OP, be aware that there are two contexts here when we're speaking about a stacks: one is an abstract data type (ADT) while the other is related to how functions are executed in memory at the machine level.

In the ADT case, conceptually you can't access an item within the stack without popping items on top. You can do tricks like pushing the popped items onto another stack until you get to the item you wanted, process it (or whatever), and then pop the items from the second stack back onto the first.

The stack referred to when you're talking about function calls is not quite the same beast. When you enter a function, space for local variables are set aside in this stack region - i.e. you push a variable onto the stack. For the scope of the function call, you can access any of these variables (computer memory is randomly accessible after all). When the function goes out of scope, then the space you're used is no longer needed so these variables are popped. In this context, the stack refers to how we reserve memory for variables.

Hopefully I've explained this without confusing you further :)

Saweet. I think I have grasped the general concept.

Now, it's time to put it to use.

Thanks everyone.
Quote:Original post by Anonymous Poster
I don't think you're following his question.

Agreed. I realized that and edited the post just after I first wrote it (You must have been pretty quick in quoting me. The unedited post wasn't up for more than a few minutes... :)

This topic is closed to new replies.

Advertisement