From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8055158949c56618 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-10-15 13:55:45 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!logbridge.uoregon.edu!uunet!sea.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: Storage Pools and alloca User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Tue, 15 Oct 2002 20:54:15 GMT Content-Type: text/plain; charset=us-ascii References: <0P_q9.20625$nb.4430@nwrddc02.gnilink.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Organization: The World Public Access UNIX, Brookline, MA Xref: archiver1.google.com comp.lang.ada:29820 Date: 2002-10-15T20:54:15+00:00 List-Id: "Frank J. Lhota" writes: > "Robert A Duff" wrote in message > news:wcczntfikew.fsf@shell01.TheWorld.com... > > "Frank J. Lhota" 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