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,436e4ce138981b82 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-17 09:41:09 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: abstract sub programs overriding Date: Wed, 17 Mar 2004 11:40:48 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <105h3dkion79348@corp.supernews.com> 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> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:6379 Date: 2004-03-17T11:40:48-06:00 List-Id: "Robert I. Eachus" wrote in message news:zYydnWeqCtXdJsrdRVn-hQ@comcast.com... > 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. OK, but that only works when the (user-defined) Initialize is in-lined. (I doubt compilers are both recognizing user-defined Initialize as special, and generating two bodies for it!) > Notice that, in this particular case, the value not finalized would also > not have any default components initialized. I suppose that's possible, but only if user-defined Initialize is in-lined. I don't know if any compilers actually do that. > 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. I don't think that can happen. Which is why Ada controlled objects usually contain a "Valid" flag or the like. > 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. Yes, but there is no such object in a user-defined Initialize call. It is default-initialized before it is passed in. If the compiler actually in-lined the call, it could eliminate the default-initialization and the Finalize call -- except that there is no permission in the standard (as amended by AI-147) to do either, and either operation could have detectable side-effects. So I wonder if such an optimization is even allowed. > 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. If the object has an explicit initial value, Initialize is never called. And if that initial value is an aggregate, it has to be built directly in the object (and none of Finalize, Adjust, or Initialize are called). That's not the case we're talking about. > I can't imagine any compiler > intentionally doing that Finalize call, in the ordinary case. That would be wrong, so I hope no compiler is doing that! The Finalize call of the target only occurs for assignment statements, not for other assignment operations. > However, > I can see that it could occur if the object is assigned a value by an > aggregate assignment inside a user-defined initialize. It *has to* occur in that case, which was Hyman's point. I don't think it can be optimized out. Randy.