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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no 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:23:25 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!cyclone1.gnilink.net!spamfinder.gnilink.net!nwrddc02.gnilink.net.POSTED!53ab2750!not-for-mail From: "Frank J. Lhota" Newsgroups: comp.lang.ada References: Subject: Re: Storage Pools and alloca X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <0P_q9.20625$nb.4430@nwrddc02.gnilink.net> Date: Tue, 15 Oct 2002 20:23:24 GMT NNTP-Posting-Host: 141.157.178.79 X-Complaints-To: abuse@verizon.net X-Trace: nwrddc02.gnilink.net 1034713404 141.157.178.79 (Tue, 15 Oct 2002 16:23:24 EDT) NNTP-Posting-Date: Tue, 15 Oct 2002 16:23:24 EDT Xref: archiver1.google.com comp.lang.ada:29819 Date: 2002-10-15T20:23:24+00:00 List-Id: "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 ) > >... > > Storage_Size is supposed to return the amount of "reserved" space, > which in virtual memory systems might be zero. ('Storage_Size is kind of > useless, actually. I've never written a program that queried > 'Storage_Size. Has anybody?) I haven't. By its very nature, the value returned is inexact, which limits its usefulness. > > Of course, this is highly platform dependant, and would often require > > machine code insertions. > > > > Questions: > > > > 1) Does any Ada compiler provide this type of storage pool? > > I believe the GNAT compiler uses a storage pool to implement > dynamically-sized stack objects. I think most other compilers > don't use a storage pool per se, but use essentially the same > run-time mechanisms as alloca. (I know of one Ada 83 compiler > that used heap allocation to implement the Ada features -- but I > think an alloca-like mechanism is better.) 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. > I don't see any reason to use such a storage pool directly. > Ada's dynamically-sized stack objects seem to do everything > alloca can do, but more safely. In fact, the Ada mechanism is > more powerful, since you can return unknown-sized objects from > functions. (I mean, unknown size at the call site -- the size is > fixed at the point of "return" in the called function. Like when > the spec of the function says "return String".) The consensus seems to be that such a storage pool would not be necessary. > > 2) If this type of storage pool was available, would you find it useful? > > No. > > > 3) Would an "alloca" storage pool be a worthwhile addition to Ada 0x? > > No, I don't think so. There's alloca-like stuff going on behind the > scenes in Ada, but I don't see why a programmer would want direct access > to that mechanism. > > Can you think of any case (in C or C++) that uses alloca, but can't be > easily translated into the existing Ada mechanisms? I can't. Neither can I, but I thought it would be worthwhile to run this idea past other Ada programmers. As you said, most (all?) Ada compilers perform an "alloca" in the background; the question is whether it is worthwhile or even desirable to bring this to the foreground. So far, all replies have indicated no desire to bring this to the foreground. 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. Thanks to everyone for your feedback.