Re: ALLOCATABLE arrays

From: Richard Maine (nospam_at_see.signature)
Date: 01/05/04 

Date: Mon, 05 Jan 2004 07:51:40 -0800

Richard Edgar <rge21@astro.su.se> writes:

>> This technique can cause problems if you have insufficient stack size
>> (especially if ou add in a second array at a later date)
>
> Granted, but why do automatic arrays _have_ to go on the stack? Why
> can't a compiler just do an ALLOCATE/DEALLOCATE behind the scenes, if
> the array is (or could) be big enough to require it?

Can be done that way. Some compilers do. One reason for using the stack
where feasible is the one mentioned earlier in this thread - stack
allocation tends to be very fast, almost negligable. Heap allocation
is not negligable at all; wouldn't be hard to make cases where the
heap allocation/deallocation would take more time than the actual
computations. That's the kind of issue that presumably prompted the
OP's query.

Some compilers seem to be "smart" about working around the limits,
putting "small" things on the stack and big ones on the heap. But
if you want your code to work well with many compilers, you can't count
on that.

Why some systems default to such small stack limits I've never figured out,
but they do. Actually, it has been explained to me more than once...but
the explanations don't make sense to me. As best as I can tell, they
amount to "in some obscure cases, large stack size defaults might cause
code to run a few percent slower." That doesn't seem to me a very good
reason for causing the many problems in common cases that result from
the small limits. But I'm sure I misrepresent the reasons for the small
defaults. Regardless of the reasons, the fact remains that the small
defaults are common (and a regular cause of questions on this forum). 

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Relevant Pages

  • Re: Microcontroller Project
    ... I'd then suggst you take a look at some more modern compilers perhaps. ... When the stack overwrites the ... registers (memory mapped) all sorts of fun things happen. ... When the stack overflows you don't see any allocation errors. ...
    (sci.electronics.design)
  • Re: alloca
    ... implemented in most compilers. ... allocating from the stack instead of allocating from the heap. ... Some people in this newsgroup will raise hell because it is a function ... I guess that other versions of stack allocation functions behave ...
    (comp.lang.c)
  • Re: Why We Use C Than C++...
    ... The reason C compilers don't adopt it is for binary ... >>compatibility with C compilers that predate function prototypes. ... >>difference (callee cleans the stack, rather than the caller) can amount to ... either standard mandates a word about performance, ...
    (comp.lang.c)
  • Re: Setting VM with WinXP-2K_Pagefile.vbs
    ... You say at ur site 'The reason is that when programs ask for ... an allocation of Virtual memory space, ... apps say 'Give me R bytes of RAM & V bytes of VM which I ... currently using the stack & bump other tasks to VM if need ...
    (microsoft.public.windowsxp.general)
  • Re: Optimizing stack access for a stack based VM
    ... Local variables should occur as natural operands of instructions (on ... from the middle of the stack. ... Global stack allocation has the potential for significant savings by ... register allocator with very few global registers does. ...
    (comp.compilers)