Re: Storage Pools and alloca

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wcczntfikew.fsf@shell01.TheWorld.com...
> > "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:
> >
> > > C / C++ sometimes cut down on the hassles of memory management by using
> the
> > > "alloca" function. The "alloca" function, which is frequently implicit,
> > > allocates storage from the stack.
> >
> > What do you mean by "frequently implicit"?
> 
> By that I mean the declaration of "alloca" is often followed by
> 
>     #pragma implicit( alloca )

Sorry, I don't know what that pragma means.  Please explain.
Is it standard C or C++?

> I recall that the first Alsys compilers actually used a mixed approach to
> stack objects: if an object was small enough, it would be allocated on the
> stack, otherwise it would be allocated from the heap. There was a compiler
> option that specified the maximum size for stack allocations.

That's not the issue I meant (although I admit I didn't make that
clear).  Yes, some machines (of those days) required that stack frames
be fairly small, so if a really big object is declared in a procedure,
it should be allocated indirectly.

The issue I was talking about was return of caller-unknown-size things.
So of we have "function F(...) return String", and it says "return
Blah", Blah would be copied to the heap, and the address of that heap
object returned, and the caller would be responsible for deallocating
it.  IMHO, that's not the best way to do it.

> The next time ACT-Europe revises the document "Common C/C++/Java Pitfalls &
> How Ada Avoids Them" document, they may wish to include something about how
> Ada can create a dynamically sized stack object with the hassles and dangers
                                                  ^^^^ ;-)
> of "alloca" calls.

Funny typo.  ;-)

- Bob