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,FREEMAIL_FROM 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-30 16:07:59 PST Path: archiver1.google.com!news1.google.com!news2.google.com!news.maxwell.syr.edu!elnk-pas-nf1!newsfeed.earthlink.net!pd7cy1no!pd7cy2so!shaw.ca!border1.nntp.ash.giganews.com!border2.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 30 Jan 2004 18:07:37 -0600 Date: Fri, 30 Jan 2004 19:07:36 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions References: <1075303237.975898@master.nyc.kbcfp.com> <9khh10pti0dn8gcp7f18ghptaifluj0fud@4ax.com> <1075390647.405841@master.nyc.kbcfp.com> <1075405582.982776@master.nyc.kbcfp.com> <1075412213.447946@master.nyc.kbcfp.com> <1075486459.94310@master.nyc.kbcfp.com> <1075495888.42130@master.nyc.kbcfp.com> In-Reply-To: <1075495888.42130@master.nyc.kbcfp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <9JednbQphIJXbIfd4p2dnA@comcast.com> NNTP-Posting-Host: 24.147.77.160 X-Trace: sv3-gbyCjG4DTnNIzW6FtbxfzwVal6rCO/MrTMpkhlQDQAa1PGexBqxM+Qg06sA69FnU5Emzl7jXE1eZik/!H2Mzo0gZh102wTXE+mSpdcJfb4Lqckhb5Fytml4Y88kOJ+LLQ1EUWJPVs+Kpkw== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:5129 Date: 2004-01-30T19:07:36-05:00 List-Id: Hyman Rosen wrote: > I'm trying to see how someone could believe that fixing an order of > evaluation doesn't make sense. Of what use is arbitrariness to the > semantics of the language? This has been explained once in this thread, but here goes again. The order of evaluation that Ada allows to be arbitrary is so that some 'common' optimizations such as common subexpression elimination and code hoisting can be done. This trade-off was explicitly accepted because without it, much of the constraint checking that Ada requires would be too expensive, and everyone would turn it off. (In fact, in the embedded world we often had to convince project management not to mandate turning constraint checking off. It does no good for the programmers to know that Ada constraint checking is essentially cost free if you don't explain that to management as well.) Let me give a simple example to explain this: for I in A'Range loop A(I) := B(I); end loop; Now 'obviously' you don't have to do the range check on A every time through the loop, but what about B? You can check that the lower bound is okay once, but it seems that you have to check against the upper limit each time. Actually in Ada 95, you don't. I won't go into the ramifications needed to explain this hear, because the real explanation is that the programmer didn't ask for it, and we don't want to prevent the compiler from handling this move the same way as: A := B(A'First..A'Last); If you really NEED the check to be repeated, write: for I in A'Range loop begin A(I) := B(I); exception when Constraint_Error => Do_Something(I); end; end loop; If A and B are Strings, you should now get a byte copy and the value of I in the exception handler will reflect the first subscript to fail the check. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush