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,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-26 12:38:45 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: 26 Jan 2004 15:38:45 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <5ad0dd8a.0401260606.76cc4415@posting.google.com> NNTP-Posting-Host: pip1-5.std.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1075149525 22228 192.74.137.185 (26 Jan 2004 20:38:45 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 26 Jan 2004 20:38:45 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:4836 Date: 2004-01-26T15:38:45-05:00 List-Id: wojtek@power.com.pl (Wojtek Narczynski) writes: > Hello, > > > The F and G functions may both update global variable X, but neither of them > > uses that X for computing the result, and this is what makes difference. > > Oh, I can easily imagine functions H and J that both do read > _and_write_ a global variable Y. > > Perhaps just expressions with value (and side effect) dependent on the > order of computation, should not be allowed. It would be a good rule, > but it is too late for it, I guess. The issue is not so simple. Consider, for example: P(F(...), G(...)); and F does "new T", and G also does "new T". Thus both F and G are both reading and writing the same variable (namely, the Storage_Pool of T). But this example is (probably) harmless, even though the 'Address of the allocated objects will be different depending on the evaluation order. The same would occur if you have a Unique_Id function that increments a global integer, and returns a unique number (private type) -- clients aren't supposed to care about the order of numbers -- just that they're unique. If F and G both call Unique_Id, there's no harm. > Or the order of computation should be explicitly defined as left to > right. Or maybe it already is, and I don't know about it :-) No, order of parameter eval is not required to be left-to-right in Ada. - Bob