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 18:43:15 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!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 20:43:12 -0600 Date: Tue, 16 Mar 2004 21:43:11 -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> <105f2jql5ge7f0a@corp.supernews.com> In-Reply-To: <105f2jql5ge7f0a@corp.supernews.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-BIbIlRyBO0TWKiVtcs/ZQ9z6AzaQlF3wDeIUOllSjxO4ccR8ybbrQ+7GkiPjVjn5A/uRtZ12OSDFpS9!4vk7z5XJ09O+xEeXxdKaZSHtEbIYSOI7RqqfVQOUEo9VOvYouhE0bCJbanO7tg== 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:6363 Date: 2004-03-16T21:43:11-05:00 List-Id: Randy Brukardt wrote: > I don't see why you think that. 'Object' in this case is not a new object; > it is a parameter passed into Initialize, and the compiler certainly cannot > assume that it is uninitialized. In any case, RM 7.6(21) is seriously > screwed up; AI-147 changes it quite a bit, mainly to eliminate bogus > 'optimizations' like the one you seem to think is allowed here. (Eliminating > this Finalize call would make a library like Claw impossible to write, > because you could have objects that are never finalized and thus never > unhooked from the lists to which they belong.) I was thinking of cases where Initialize is called implicitly, and the compiler can determine that Object is never referenced before it is overwriten. In that case, of course, the compiler can eliminate an implicit Finalize. This shouldn't break your code. But this could/should only happen when the an object is being created and assigned a new value by the implicit call to Initialize, with no reference to its previous value. If an existing object is passed to Initialize explicitly, in this case the previous value would have to be finalized. Notice that, in this particular case, the value not finalized would also not have any default components initialized. I was suggesting to Hyman that he might want to try to find a case where compilers DO finalize a value that does not have default component values assigned. As I understand AI-147, it allows some calls to user defined Finalize operations to be eliminated, but not Intialize and Finalize pairs where the Initialize is user defined. Eliminating a Finalize call on an object that has not been initialized seems legal to me. This can only happen AFAIK, in these cases where the object has an explicit initial value, and the Finalize call occurs before the assignment of the initial value. I can't imagine any compiler intentionally doing that Finalize call, in the ordinary case. However, I can see that it could occur if the object is assigned a value by an aggregate assignment inside a user-defined initialize. -- Robert I. Eachus "The only thing necessary for the triumph of evil is for good men to do nothing." --Edmund Burke