[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is Linux Unix?

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 the

what? 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...


Reply to: