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-02-25 07:44:15 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!adsl-213-200-246-247.cybernet.CH!not-for-mail From: Vinzent 'Gadget' Hoefler Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: Wed, 25 Feb 2004 16:43:33 +0100 Organization: JeLlyFish software Message-ID: References: <1075987360.225622@master.nyc.kbcfp.com> <40236C0B.E988E003@0.0> <1077634311.254581@master.nyc.kbcfp.com> <1077718871.47635@master.nyc.kbcfp.com> <54cp3095jmv8s17h63d4bjdus0tec7l7pt@jellix.jlfencey.com> <1077721343.481619@master.nyc.kbcfp.com> NNTP-Posting-Host: adsl-213-200-246-247.cybernet.ch (213.200.246.247) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: news.uni-berlin.de 1077723853 53110175 I 213.200.246.247 ([175126]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:5792 Date: 2004-02-25T16:43:33+01:00 List-Id: Hyman Rosen wrote: >Vinzent 'Gadget' Hoefler wrote: >> The philosophy that the semantics of a program should be the same, no >> matter if you choose to write "f :=3D a + b;" or "f =3D b + a;" = instead. > >But Ada does not have that philosophy, so that cannot be the reason >to maintain the feature. It has it for built-in functions where the compiler knows that it doesn't make any difference. >When "+" is a user-defined subprogram, its >operands are always passed in the order written; a + b is always >invoked as "+"(a, b) and never as "+"(b, a). Well, yes. Think of the case where "+" might not be commutative. I guess it would be too much burden to specify in the standard that the compiler should be able to figure out if this is the case or not in each particular case. The simplest example would be a "+" where a and b have different types. ;-) >> The only difference is that unfortunately all Boolean >> operations happen to be sequence points here. > >"Unfortunately"? Built-in && is the equivalent of Ada "and then" >and || is the equivalent of "or else". What exactly makes that >unfortunate? There's no equivalent of an Ada's "and" and "or" where the compiler can evaluate if the comparison with the result of a costly square-root function should be delayed until we can figure out if the simple boolean flag already gives us the result: |if (Sqrt (x) > 5.0) and b then ... So you should always write this in the most efficient order then, even if it might not be the most intuitive way. BTW, the above is another reason why you shouldn't write functions with side effects, because if you do the compiler *has* to evaluate Sqrt, too. :-) Vinzent.