I know that by using operator new() I can exhaust memory and I know how to protect myself against such a case, but can I exhaust memory by creating objects on stack? And if yes, how can I check if object creation was succesful?
Thank you.
views:
214answers:
7You can exhaust a stack. In such cases, your program will probably crash with the stack overflow exception immediately.
A stack has a size too, so you can look at it as simply a block of memory. Variables inside functions for example are allocated here. Also when you call a function, the call itself is stored on the stack (very simplified, i know). So if you make a infinite recursion (as mentioned in another answer) then the stack gets filled but not emptied (this happens when a function returns, the information about the call is "deleted") so at some time you will fill the whole space allocated for your programs stack and your app will crash.
Note that there are ways how to determine/change the size of stack.
Yes, see the site's name. You can't really check that the object creation is successful -- the program simply crashes on stack overflow.
Just look at the title of this site and you will see the answer. Write some infinite recursion if you want to see "live" what happens.
i.e.
void fun() { fun(); }
Memory is not infinite, so wherever you allocate objects you will eventually run out of it.
Ok, but you'll need sharp reactions to spot when the 'object creation' succeeds.
class MyObject {
private:
int x
public:
MyObject() { x = 0; }
};
int main(int argc, char **argv) {
IWantToExhaustTheStack();
return 0;
}
void IWantToExhaustTheStack() {
MyObject o;
IWantToExhaustTheStack();
}
Now compile and run this, for a very short while your object creation will work. You will know that the object creation has failed, when your program fails.
Joking aside, and in response to your updated question, there is no standard way to determine the stack size. See : This Stackoverflow Question in relation to Win32. However, the stack is used to call methods and hold local temporary and return variables. If you are allocating large objects on the stack, you really should be thinking of putting them on the heap.
Yes, you can exhaust the stack. On common systems, the hardware/OS traps that and aborts your program. However, it is hard to do so. You would have to either create huge objects on the stack (automatic arrays) or do deep recursion.
Note that, if you use common abstractions such as std::string
, std::vector
etc., you can hardly ever exhaust the stack, because while they live on the stack, they have their data on the heap. (This is true for all STL containers coming with the std lib except for std::tr1::array
.)
Yes, you can exhaust the stack and you cannot test whether object creation fails because after failure this is already too late.
Generally, the only way to protect from stack overflow is to design application in a such way that it will not exceed given limit. I.e. if recursion modifies an image then put limit on image size or use other algorithm for huge images.
Watch recursions (not too deep), watch alloca (not too much). Watch peeks when examining stack usage.
In OpenSolaris there is few functions that lets you to control the stack.