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-02-04 09:13:22 PST
Path: 
 archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!news-out.visi.com!petbe.visi.com!news.octanews.net!ash.uu.net!spool.news.uu.net!not-for-mail
Date: Wed, 04 Feb 2004 12:13:20 -0500
From: Hyman Rosen <hyrosen@mail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: In-Out Parameters for functions
References: <1075741279.952497@master.nyc.kbcfp.com>
 <16nu1099ekujjbpe9dqvs3noi9sdcfja6e@4ax.com>
 <1075817212.745748@master.nyc.kbcfp.com>
 <padv10hc6ndicrrem6beftvnh18gr4f27j@4ax.com>
 <1075824683.769215@master.nyc.kbcfp.com>
 <pan.2004.02.03.22.38.49.622001@email.ro>
 <1075851506.238480@master.nyc.kbcfp.com> <4020C947.81A6D703@0.0>
 <1075907239.138068@master.nyc.kbcfp.com>
 <123220to3lncqppiu5vb4up7j0drs5mf25@jellix.jlfencey.com>
 <1075910062.117961@master.nyc.kbcfp.com>
 <ds7220pvjfbr06c7f42dcvvvnppj6bkv67@jellix.jlfencey.com>
In-Reply-To: <ds7220pvjfbr06c7f42dcvvvnppj6bkv67@jellix.jlfencey.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Organization: KBC Financial Products
Message-ID: <1075914801.41191@master.nyc.kbcfp.com>
Cache-Post-Path: master.nyc.kbcfp.com!unknown@carrots.nyc.kbcfp.com
X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/)
NNTP-Posting-Host: 204.253.250.10
X-Trace: 1075914801  10865 204.253.250.10
Xref: archiver1.google.com comp.lang.ada:5239
Date: 2004-02-04T12:13:20-05:00
List-Id: <comp.lang.ada>

Vinzent 'Gadget' Hoefler wrote:
> Maybe. But it will also lead to more stupid code because we now know
> about the evaluation order and thus can (or even: must) do
> optimizations ourselves. That sort of optimizations that we would
> normally leave to the compiler.

Do you have an example? What sort of optimization is implied by
order of evaluation that would lead a programmer to choose one
way over another?