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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5d3a1501d97dab65 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: C to Ada : a piece of code Date: 1996/09/10 Message-ID: #1/1 X-Deja-AN: 179596352 sender: news@organon.com (news) references: <3231732C.2781@virgoa4.in2p3.fr> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-09-10T00:00:00+00:00 List-Id: In article <01bb9e40$d0312d80$348371a5@dhoossr.iquest.com> "David C. Hoos, Sr." writes: > ... > > Well, sure. I guess I should have included an ellipsis after the end > > loop to show the rest of whatever you might want to do. Also, there's > > no reason why you couldn't just eliminate the declare block by means > > of a subprogram. As for not using malloc in this case, I see that as > > a real good thing - no memory management to deal with. As far as > > calloc, you can just add an initializer (for unknown reasons since he > > just sets all the values anyway). And you can always pass such an > > array around via parameters or function returns - again no need for > > the allocator. > > Please explain to me how, (since the size of the array required is acquired > through standard input) if dynamic memory allocation is not used, you're > going to acquire static memory of the specified size, to which access can > be safely passed without it's going out of scope. In fact, gnat has gotten > smarter than, say, VADS, in this regard, in that it will tell you when > you're passing access to memory that would be out of scope. The size of the array stays with it - the type is unconstrained. If it is a parameter, then the client has the space allocated for it. If it is a function result, the result is (typically) left on the stack via a "stack shuffel" or by use of parallel stacks (isn't this how GNAT goes about it now?) Some early implementations also implicitly used the heap. type My_Array_Type is array ( Natural range <> ) of integer; procedure P ( X : in out My_Array_Type ) is begin for I in X'Range loop X(i) := i; end loop; end P; ... A : My_Array_Type(1..10); ... P(A); function F ( X : Whatever_Type ) return My_Array_Type is A : My_Array_Type(0..Get_Upper_Bound(X)) := (others => 0); begin ... return A; end F; ... A : My_Array_Type := F(...); ... If A'Length = ... then ... No user level heap allocations anywhere (and probably no heap allocations period). See now? > > Shrug. It uglifies the dynamic array allocation (needing a -1). He > > said _equivalent_ Ada, not "identical" word for word translation. In > > fact, an identical word for word translation of this particular case > > is just bad Ada. > > The trade off, (in those frequent cases where 0-based indexing is more > appropriate) is the one-time ugliness of the allocation, vs. the every time > ugliness of the references which need something like Vect'FIRST subtracted > during index computation. First, any such operation (done for constraint check or something before the loop) is not visible to the user. Second, no even remotely decent compiler will do this computation for _any_ of the actual "indexing" in such a loop as that in question. Third, I didn't mean that the 0 based part was the "bad Ada" - the direct user heap allocation, given the provided context, is what is not "good" Ada style. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com