Quote:Original post by Necator
yes, but I guess the OS can introduce some reservations to that statement. Swapping out/in pages etc.
Paging has nothing to do with and is not a solution for running out of stack space.
Allocating memory on the stack or heap
Paging has nothing to do with and is not a solution for running out of stack space.
Author
Thanks for all the answers guys, that clears it up. And special points to Anon Mike for the explicit reference to a function!
- Goishin
- Goishin
Quote:Paging has nothing to do with and is not a solution for running out of stack space.
Yeah, true. What I was thinking was that the OS might swap out some parts of the stack and move the remaining part, allowing the stack to grow even further. But I realized that it wouldn't work that well
Quote:Original post by Necator
You have to remember that static variables are only stored once, global and local statics the same. I don't know exactly where it puts them, but since there is only one instance, the compiler can basically put them anywhere and hard-code their adresses.
And that is pretty much what it does. The compiler uses a separate chunk of memory to put all the static stuff into, so it's not exactly stack- or heap-allocated.
Quote:
nd if stack memory is around a meg, aren't you in danger of of running out of stack space when using recursion(assuming whatever you're recursing is going to be doing a WHOLE bunch of recursing)?
yes, but I guess the OS can introduce some reservations to that statement. Swapping out/in pages etc.
Yep, recursion can be dangerous like that. [smile]
Of course, in the languages that rely on recursion, there are plenty of solutions for this (an obvious one could be a bigger stack. But also in those languages, most recursive function calls can be optimized to reuse the same stack frame, so the stack usage doesn't grow. That's also possible in some cases in C++, but you have to be more careful with your code to make it possible, and it requires a bit more effort from the compiler. On the other hand, it's also less important since C++ programmers don't rely as much on recursion.
You can test creating a stack overflow by infinity recursion:
The return addresses and the storage space for i (both 4 bytes on
32 bit machines) will be pushed onto the stack with each function call.
As it is an infinity loop, it will fill up the stack space, causing
a stack overflow exception to generate.
Stack space is in RAM, just like the heap. However, the stack
is directly manipulated through simple pushing and poping.
The heap has to be allocated (and managed) alot more, as your
program either directly (or indirectly) has control over each byte
(rather then a simple push or pop)
Use the stack whenever possible. As others explained (and shown above),
heap memory is generally slower then the stack. However, it also has
more control. Hence, you have to balance control and speed.
Dont introduce bad programming habits here--Alot of people (*Ahem*, Andre
Lamothe), uses *Tons* of globals to favor speed--which is not neccessary.
Using To much stack space is just as bad as to little[smile]
void foo () { int i=0; while (1) foo ();}The return addresses and the storage space for i (both 4 bytes on
32 bit machines) will be pushed onto the stack with each function call.
As it is an infinity loop, it will fill up the stack space, causing
a stack overflow exception to generate.
Stack space is in RAM, just like the heap. However, the stack
is directly manipulated through simple pushing and poping.
The heap has to be allocated (and managed) alot more, as your
program either directly (or indirectly) has control over each byte
(rather then a simple push or pop)
Use the stack whenever possible. As others explained (and shown above),
heap memory is generally slower then the stack. However, it also has
more control. Hence, you have to balance control and speed.
Dont introduce bad programming habits here--Alot of people (*Ahem*, Andre
Lamothe), uses *Tons* of globals to favor speed--which is not neccessary.
Using To much stack space is just as bad as to little[smile]
Author
So here's what I did.
When I tried it, I got all the way up to 4777 before I got dumped back to the command prompt. I guess I was expecting some sort of error message or something. [oh]
- Goishin
void foo (int i) { i++; printf("up to %d\n",i); while (1) foo(i);}void main(){ int i = 0; foo(i); return;}When I tried it, I got all the way up to 4777 before I got dumped back to the command prompt. I guess I was expecting some sort of error message or something. [oh]
- Goishin
This should work:
MSVC++ gives me a warning about runtime stack overflow from foo()
#include <iostream>void foo () { static int i=0; std::cout << i++ << std::endl; foo ();}int main () { foo (); return 0;}MSVC++ gives me a warning about runtime stack overflow from foo()
A faster way to get the stack blown up is like this:
here is the full output of my program before crashing:
Up to 0
Up to 1
Up to 2
Up to 3
Of course you could also overflow it by just making one huge array..
struct WOAH_THISISBIGSTRUCT { int junk [50000];};void crazy (WOAH_THISISBIGSTRUCT wtibs){ static int i = 0; printf ("Up to %d\n", i++); crazy (wtibs);}here is the full output of my program before crashing:
Up to 0
Up to 1
Up to 2
Up to 3
Of course you could also overflow it by just making one huge array..
LOL! --That code killed my MSVC++ optomizing compilier![grin]
(I am unable to compile it because the compilier keeps crashing[grin])
(I am unable to compile it because the compilier keeps crashing[grin])
Author
Oh man, that was hilarious!
And that struct name? WOAH_THISISBIGSTRUCT
Priceless...
- Goishin
And that struct name? WOAH_THISISBIGSTRUCT
Priceless...
- Goishin
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
