Re: Is Linux Unix?
Ryo Furue wrote:
Erik Steffl <firstname.lastname@example.org> wrote in message news:<2q4wL-5tQemail@example.com>...
[. . .]
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
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...