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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!rutgers!gatech!hubcap!billwolf From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) Newsgroups: comp.lang.ada Subject: Re: Collective response to := messages Message-ID: <3721@hubcap.UUCP> Date: 2 Dec 88 20:21:37 GMT References: <10917@ulysses.homer.nj.att.com> Sender: news@hubcap.UUCP Reply-To: billwolf@hubcap.clemson.edu List-Id: >From article <10917@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum): > In article <755@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes: >> >>There seems to be a point of confusion concerning overloading of ":=". >>Some people assume that the (overloaded) semantics of ":=" apply to >>parameter passing. This seems to be a reasonable assumption, and I >>think the current Ada parameter passing semantics are equivalent to >>the current Ada assignment semantics. > > They are not the least bit equivalent, for several reasons. The most > obvious reason is that an implementation is free to pass composite > parameters by reference, although no implementation can "assign by > reference". Sure, for "in out" mode. But for modes "in" and "out", failure to use the ADT's assignment procedure causes major problems: "out" mode: Programmer assigns the parameter a value, and the value is copied back to the actual parameter. Unfortunately, the portions of the actual parameter which were formerly accessible by pointers are now uncollectable garbage. "in" mode: Programmer assumes that this is a "pass by value" and makes modifications. Since ADT contains pointers, modification echoes through to the actual parameter. Programmer could also invoke DESTROY, blowing away major portions of the actual parameter.