-6

Are there any problems when using the stack instead of the heap?

Basically I want some 200 positions in memory (or more, 1000, who knows, this is hypothetical anyways), I can allocate it in the stack using an array, or on the heap using malloc(). On the heap I have to remember to always free() the memory...but using the stack, as soon as the function returns, all the memory is nicely cleaned for me.

I am just wondering if there are any issues with holding large amounts of memory on the stack. As far as I know, the stack and the heap are basically the same, just they sit on opposite sides in a RAM frame, and they grow towards the other, like in the image below.

Stack and Heap

Michel Feinstein
  • 13,416
  • 16
  • 91
  • 173
  • 3
    stack space is limited. If you do not know how much you want just use a `vector`(C++) and don't worry about the memory management. – NathanOliver Feb 16 '16 at 22:25
  • Isn't it as limited as the heap? Since both grow to the same reserved space – Michel Feinstein Feb 16 '16 at 22:26
  • Why the urge to downvote??????????? Seriously people, we downvote if there is something wrong in the question language, not about asking a question..... – Michel Feinstein Feb 16 '16 at 22:27
  • No. think of the stack space as like program memory. It is small and is used just by the program. The heap is the ram and it is what it says. It just a heap of memory. – NathanOliver Feb 16 '16 at 22:28
  • I say not in practice. The default stack usually is a few MB depending on the OS. – drescherjm Feb 16 '16 at 22:28
  • 4
    Your understanding is only partial at best. But there are many existing questions on this topic already. Read some of those to see if they answer your question. For example: [What and where are the stack and heap?](https://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap) – kaylum Feb 16 '16 at 22:28
  • Well, in college we learned in class that the OS reserves a space for the program, and the heap grows towards the stack, just like in the image, so AFAIK the reserved space can be used by both and once stack and the heap collides you have a problem (and the OS can detect and reserve more). – Michel Feinstein Feb 16 '16 at 22:30
  • 2
    This old simplified model does not account for more than 1 thread of execution in your program. – drescherjm Feb 16 '16 at 22:32
  • In classical implementations, local variables are stored on the stack, along with return addresses. For each nested branch, there is data appended to the stack. The stack unwinds when execution returns from a function. One reason to limit stack variables is to reduce the interference with the function calls. – Thomas Matthews Feb 16 '16 at 22:35
  • One reason for downvotes can be seen by Googling your exact title: 'About 12,100,000 results'. I did not downvote your question but, then again, I've run out of downvotes for today.. – Martin James Feb 16 '16 at 22:36
  • 1
    The general rule of thumb is to allocate large data structures in *automatic storage (i.e. global variables)* or in dynamic memory (a.k.a. heap). Pass large items by reference or pointer. Pointers and references take up less room than the large objects. Entire objects may be copied when passed to functions without using pointers or references. – Thomas Matthews Feb 16 '16 at 22:37
  • When I google about it, I see an ocean of "this is the stack...this is the heap"...but I just don't see why it's bad to allocate too much memory on the stack – Michel Feinstein Feb 16 '16 at 22:38
  • @ThomasMatthews, yes, thanks, I am aware of by value and by reference, my only doubt was about why not use the stack to hold large data. – Michel Feinstein Feb 16 '16 at 22:39
  • 1
    Just because the diagram shows that the stack grows in a certain direction does not equate to it being allowed to grow all the way. Maximum stack sizes are typically limited to a much smaller value than the maximum heap size. – kaylum Feb 16 '16 at 22:40
  • What do you mean by "One reason to limit stack variables is to reduce the interference with the function calls.", how would it interfere if every function gets its own stack space? – Michel Feinstein Feb 16 '16 at 22:40
  • @kaylum well, that will be a really good addition to every diagram on google images – Michel Feinstein Feb 16 '16 at 22:41
  • Typical stack sizes on 32 bit or 64 bit OSs are a few MB. – drescherjm Feb 16 '16 at 22:41
  • 1
    ***On the heap I have to remember to always free() the memory...but using the stack, as soon as the function returns, all the memory is nicely cleaned for me.*** Not if you use c++. I mean std::vector ... will manage the memory for you. In c yes you will have to worry about malloc / free. – drescherjm Feb 16 '16 at 22:49
  • The growing-together stack and heap is often used on systems with a small amount of memory, but I don't think modern PCs do that, they set aside a stack area on thread startup and it can always grow to fill that whole area – M.M Feb 16 '16 at 23:01

2 Answers2

1

First of all - heap and stack are not c++terms. They are implementation details.

Implementations using stack and heap (which probably most - if not all - do) usually have an upper limit of the stack size. So placing huge variables on the stack can cause stack overflow (which typically leads to unpredictable errors).

However, the stack has benefits over the heap so use it whenever you can - provided you don't put huge variables on the stack.

Notice - that most c++ containers, e.g. a vector, list, deque, can be placed on the stack without problem because they only put a few bytes on the stack and allocate the real data-container on the heap.

Support Ukraine
  • 42,271
  • 4
  • 38
  • 63
  • Yes, I know, but as far as I could see, the stack would overflow the same as the heap will overflow....but after the comments, now I know the simplistic model of memory sharing is not used anymore. – Michel Feinstein Feb 16 '16 at 23:54
-3

Main "problem" using stack - lifetime of that variables controlled by execution flow not by the developer. Though it is easier when variables are destroyed automatically when they go out of scope in some cases it is necessary and simpler to have data which lifetime controlled by developer, not compiler. Another issue - on standard C++ you can only allocate data on stack which size is known on compile time which is not the case for heap.

Slava
  • 43,454
  • 1
  • 47
  • 90
  • Yes, I know, and that's why I rather use the stack to avoid memory management, when it's possible, of course...but my question isn't about how they work, but if there are any side effects from using the stack when the heap is generally used, like for holding large amounts of data. – Michel Feinstein Feb 16 '16 at 22:44
  • 2
    I think anonymous downvoters will soon ruin community here. – Slava Feb 16 '16 at 22:48