Re: Stack or Heap

Richard Maine <nospam@xxxxxxxxxxxxx> wrote:
Louis Krupp <lkrupp_nospam@xxxxxxxxxxxxxxxxx> wrote:
(snip)

Indeed. Segmentation faults are sort of user-hostile for debugging to
pretty much anyone who isn't a Unix geek, but they sure are a lot better
than (and are a completely different thing from) the computer "locking
up."

The days of DOS and no memory protection aren't that long ago...

(snip)

They may try, but my observation is that quite often the end result is
exactly the opposite. There are *MANY* cases of people asking on this
newsgroup why their program failed when it turns out that the reason was
it ran out of stack space. The combination of default low stack size
limits, combined with a default that puts many arrays on the stack
pretty much guarantees that you can't do much of substance without
learning enough about the stack to either know how to increase its size
limit or control what goes on it. Perhaps things have improved with
recent versions of compilers, but I just know that I see variants of
that question here a *LOT*.

When memories were small, a small default stack made some sense.
I am not sure why it doesn't increase, other than tradition.

I still don't understand why default stack limits are so low. Yes, I've
seen explanations, but I still don't understand how they support the
typical defaults. The explanations basically seem to fall into one of
two cases: that there are trivial performance benefits in obscure
cases, or that one particular kind of broken program will abort fairly
quickly instead of hogging lots of memory before aborting. I just don't
understand how those benefits, which seem obscure to me, justify forcing
pretty much every programmer to learn enough about stack management to
know how to work around the effects of the defaults.

When I first started using OS/2 (version 1.0), it used the same
LINK program as DOS. (I believe it was dual mode, and could generate
either DOS or OS/2 executables.) OS/2 had a dynamic stack such that
you could allocate a really huge (even for today) stack, and it wouldn't
actually use even swap space until you actually used the space.
But LINK still gave it the default 2K or so stack.

I would prefer that the defaults were such that an average Fortran
programmer could get by without needing to know anything about system
stacks and heaps. Unless things have changed with recent compiler
releases (which is possible), that hasn't been the case.

BTW, if you ask a typical C-programmer why the above code crashes, he
will simply advise you not to use arrays! Most experienced C
programmers never use arrays prefering linked lists etc.

Based on my experience, I would say that this is not the case. Any
programmer who would tell you to use a linked list when you need an
array -- in any language -- is smoking something.

Indeed. Somone must have an awfully narrow view of what constitutes
"most experienced C programmers". I personally know lots of experienced
C programmers. Not one of them would make a statement like that - not
one. Maybe the ones I know only smoke the milder stuff. I also have
substantial experience in maintaining C codes. (I don't like it, but
I've had to do it often enough). Darn near all of them of any substance
use arrays extensively. Sure, some of them also use things like linked
lists, but it is by no means a replacement.

Well, technically arrays aren't used so often in C (at least C89),
as the size has to be a compile time constant. Instead pointers
and malloc() are used to dynamically allocate the space. The reference
is the same as an array (for the 1D case). (For the 2D or more case,
it looks the same but is actually different.) Linked lists are
used, but not so often as the above statement would indicate.

Anyone who thinks that all arrays should be replaced by linked lists not
only needs to stop smoking that stuff, they also need to retake CS 101
or whatever comparable course covers some of the most basic concepts in
data structures. There exists more than one form of data structure;
different ones are better for different purposes. Hammers just don't
work very at screwing in screws. "Experienced" is about the opposite of
the description I would use for such a person. I'd say closer to "too
naive to be ready for real work."

I agree.

-- glen
.

Relevant Pages

  • Re: ALLOCATABLE arrays
    ... || If try to create a very large array on the stack and you do not have enough ... || Allocating on the heap gives you access to a hell of a lot more memory (well ... and "heap" (and there probably are/were some computers which don't/didn't ... | Automatic arrays are always allocated on the stack. ...
    (comp.lang.fortran)
  • Re: Fortran memory allocation (stack/heap) issues
    ... > rather than Fortran, ... dynamic allocation, and relatively little stack allocation. ... value return and arrays by reference. ...
    (comp.lang.fortran)
  • Re: Stack or Heap
    ... it ran out of stack space. ... combined with a default that puts many arrays on the stack ... which conforms with the C-standard will compile without error ... seg fault due to stack/heap issues. ...
    (comp.lang.fortran)
  • Re: Need some help understanding array definitions
    ... Data structures defined with VARIABLE, CREATE, VALUE, CONSTANT, and related words are, indeed, all global. ... Unlike some languages, Forth doesn't discourage defining global data structures, but it's important to understand their proper use. ... They provide for "persistent" data, as well as space for strings and arrays. ... Strings and arrays should be in defined data structures and referenced by address and length or address on the stack. ...
    (comp.lang.forth)
  • Re: heap allocation of arrays
    ... | to force all arrays to be allocated on the heap. ... | the stack would be replaced with pointers on the stack. ... | heap is easier to detect than failure to allocate space on the ...
    (comp.lang.fortran)