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,29fe9a340e0d180d X-Google-Attributes: gid103376,public From: Andre Spiegel Subject: Re: Depending on passing mechanism Date: 1997/10/17 Message-ID: #1/1 X-Deja-AN: 281810336 Sender: spiegel@moon.inf.fu-berlin.de References: <622b4t$nhe$1@gonzo.sun3.iaf.nl> Organization: Freie Universitaet Berlin X-Access: 16 17 19 Newsgroups: comp.lang.ada Date: 1997-10-17T00:00:00+00:00 List-Id: Regarding parameter passing mechanisms, particularly in Distributed Systems, I think there are two possible approaches. (1) Leave it up to the programmer to chose by-copy vs. by-reference for each subprogram parameter explicitly. This way, the programmer can chose the passing mechanism that best fits a given situation. For example, if the call goes across a distribution boundary, by-copy might be preferable, etc. Drawback: the decisions for one particular setting, machine, compiler might not be optimal for another one. For example, if the call that used to go across a distribution boundary becomes a local call at a later stage, by-copy might impose an unnecessary cost. Also, the programmer might not have enough information to make the right decision, or simply not care. The advantage of this scheme, however, is that program behavior never changes if you move to a different target, compiler, or distribution scenario. It might become less efficient and sub-optimal, but nothing worse. Some of the proposed schemes for CORBA "Objects-by-Value" work this way. Ada does not let you do it -- at least not quite, see below. (2) Let the compiler make the decision. The programmer specifies the "intent" of the parameter in a more abstract way. This is what Ada always did, through "in", "out", and "in out". The advantage is higher efficiency. Passing mechanisms may be employed automatically in an optimal way to make use of hardware characteristics, and to support given distribution scenarios. The drawback is non-deterministic program behavior, if only in rare circumstances that could well be called pathological. However, Ada 95 does alleviate this somewhat, through "access" parameters. If the programmer uses "in out", he says in fact that he is willing to accept the non-determinism, and leaves the optimal decision to the compiler. But if for some reason he needs clear-cut behavior, "access" parameters can be used to guarantee by-reference semantics, no matter what. There is no corresponding means to force _by-copy_ semantics in Ada 95. However, one might say that "in out" parameters are conceptually closer to by-copy than to by-reference. The reason is that if an "in out" parameter is passed by reference, the callee does not "see" this reference, and hence, cannot store it anywhere to create additional aliasing. If the parameter is copied, the _value_ is in fact copied, and the reference broken. I think this way of handling parameters makes Ada particularly suitable for distributed systems with a high degree of transparency, i.e. where the programmer does not necessarily know where distribution boundaries will be at run-time. Andre Spiegel Free University of Berlin