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,436e4ce138981b82 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-16 17:54:27 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!zeus.visi.com!news-out.visi.com!priapus.visi.com!orange.octanews.net!news.octanews.net!green.octanews.net!news-out.octanews.net!news.glorb.com!border1.nntp.ash.giganews.com!border2.nntp.sjc.giganews.com!border1.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: Tue, 16 Mar 2004 19:54:26 -0600 Date: Tue, 16 Mar 2004 20:54:25 -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: abstract sub programs overriding References: <1078776213.376775@master.nyc.kbcfp.com> <1078839257.157439@master.nyc.kbcfp.com> <5cmr40t76va200betf07b7bd6er05ltto9@4ax.com> <1078845298.702789@master.nyc.kbcfp.com> <0ipr40thtf86b520a0qdi003aj87gtuhd4@4ax.com> <1078849973.701176@master.nyc.kbcfp.com> <1078924150.268074@master.nyc.kbcfp.com> <1078934469.744922@master.nyc.kbcfp.com> <1078949096.760629@master.nyc.kbcfp.com> <1079013337.572283@master.nyc.kbcfp.com> <9_mdnfzBlfEC3M_d4p2dnA@comcast.com> <1079361579.900651@master.nyc.kbcfp.com> <1079466915.690786@master.nyc.kbcfp.com> In-Reply-To: <1079466915.690786@master.nyc.kbcfp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.128.39.153 X-Trace: sv3-xQXYZE72M4BV1MWE/8laZmyl9eDbJPFVTHzywZfJSuXZgdGZeL0ekW6hYWerzLATjm/ya71FLGeLp8n!XY9bKdToAxU3lj56NOYBfxg2cx8dRVm4JsHK4ymUjIGJo/MduJ/bW8iNPMoTSQ== 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:6361 Date: 2004-03-16T20:54:25-05:00 List-Id: Hyman Rosen wrote: > I don't think compilers can eliminate that Finalize call. 7.6/17 says, > without listing any exceptions, "The target of the assignment_statement > is then finalized." All the other permissions deal with the temporary > anonymous object that the canonical semantics create. Look at the last sentence, "As explained below, the implementation may eliminate the intermediate anonymous object..." then at 7.6(21): "For an aggregate or function call whose value is assigned into a target object, the implementation need not create a separate anonymous object if it can safely create the value of the aggregate or function call directly in the target object." In the RM, then has a very specific meaning. If the action before the then is not taken, then neither is the action following the then. In this case, anything else would be silly, since finalizing the target after constructing the new value in it would be a disaster. Of course, there are many cases where you can't eliminate the finalization, and that is covered by "...if it can safely create..." Certainly not finalizing an uninitialized object is safe. (Or at least there is no guarantee that such objects are finalized.) -- Robert I. Eachus "The only thing necessary for the triumph of evil is for good men to do nothing." --Edmund Burke