Ryo Furue wrote:
Erik Steffl <steffl@bigfoot.com> wrote in message news:<2q4wL-5tQ-3@gated-at.bofh.it>... [. . .]My point is that it's really is a choice. The fact is that in majority of cases the heap is the better choise. But, I don't see any inherent reason why you shouldn't use the stack for large data. I said thewhat? I just provided you with bunch of reasons. And you provided another one (you can get around the problem you described by having the variable declared in highest level function where it's used, in your example above the workspace would be allocated in whoever calls f and would be passed as an argument to f). In a particular situation these might not outweight whatever advantage you get for using stack but that does not mean there are no reasons.stack-is-not-for-large-data is "inertia", but it may be better called a myth. By the way, I don't know how hard to keep track of stack use. But, the stack is released when the function is finished. Isn't it, then, harder to keep track of heap use? I've heard a lot about "memory leak", which refers to forgetting to 'delete' allocated heap memory. I'm yet to hear "stack leak" :) Of course, I'm joking. Please don't take this seriously.of course there are reasons to use one or another, I am not advocating heap over stack, you asked for sme reasons why one should be careful about using stack (you wrote: ...shouldn't use much stack ... nobody seems to be able to give a convincing argument ...) so I provided you with some reasons. Obviously, a general rule like that does not apply in all situations...Then we agree! I may have misunderstood what you said. I agree that "one should be careful about using stack" (your words) but I don't agree that one "shouldn't use much stack" (mine). The reasons you gave are reasons for being careful about stack, not ones that one should't use it in any case. Why am I arguing this? Because I once used a Unix system where the system administrator imposed a low stacklimit. I wanted to use large stack in a situation I described earlier. Before asking the system administrator to raise the limit, I asked knowledgeable people if there's some inherent reasons against using large stack. The answers I got were that you should use heap for large data, without reference to reasons. That was a long time ago. But even today I sometimes see people saying something like: if your program uses more than 2MB of stack, your program is broken.
well, it was a lot worse before, compilers were poor, sometime you could overwrite stack or heap, there was a lot less memory overall etc. So I guess part of the stack-is-bad mindset is just inertia...
I forgot to add that Stroustrap says that lot lot of memory management problems can be avoided by simply using variables on the stack and not dynamically allocate it using new (so you're not alone:-), I don't have reference but I guess you'll be able to find it if you want to... If you use STL (or something similar) you can have the containers in the stack and let the containers (better debugged than your code) handle the allocation of the data (that way you get advantage of using heap for large data plus the advantage of stack - code is cleaner/shorter, data are automatically freed without you having to take care of it and you can handle the out of memory error). Not saying that you should use that, just that there are various combinations that can be used, depending on what one needs...
erik