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-17 18:39:49 PST Path: archiver1.google.com!news1.google.com!news.glorb.com!newsfeed3.easynews.com!easynews.com!easynews!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: Wed, 17 Mar 2004 20:39:48 -0600 Date: Wed, 17 Mar 2004 21:39:47 -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> <105h3dkion79348@corp.supernews.com> In-Reply-To: <105h3dkion79348@corp.supernews.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3vydndmUiYRplsTdRVn-sQ@comcast.com> NNTP-Posting-Host: 24.128.39.153 X-Trace: sv3-pLa8MTYkMv3YDga4r+kv9Vz5p4zxsfSStv9TAdyn8iJaUFGzAVxJIlYBnHeVyclWqKWt9UiPNlR9+jM!9S1ftV0GeaZfKyout/V9v4w6liu72xfehUjwopBtf0JNW8cs1FSdLDxr0veAag== 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:6388 Date: 2004-03-17T21:39:47-05:00 List-Id: Randy Brukardt wrote: >>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!) I agree here. My point was that it may be legal, but it is unlikely that any compiler does 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. Again, agree, especially on the last line. >>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. The Valid flag (or checking if an access value is non-null which is what I sometimes do) is not relevant here. My original point was that although the language rules seem to imply that there is a loophole, any compiler is going to have to do a lot of work--to be able to do more work proving that there are no external effects of the optimizations. >>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. As I was writing this originally, I thought about the curse in Ruddigore and "Yesterday upon the stair I met a man who wasn't there. He wasn't there again today. I wish that man would go away." -- Hughes Mearns (1875-1965) I don't wonder if the optimization is allowed, I wonder if there are inifinitely many uninitialized objects that are also not finalized, or if the number is somehow finite. In any case it seems clear to me that an object that doesn't get far enough along the track toward existing as to begin default initialization does not need to be finalized. The interesting questions concern partially and fully initialized objects. >>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. Whoops, that one sent me back to the reference manual. First, an aggregate of a controlled type always results in a call to some Initialize, except perhaps inside of Ada.Finalization where you can use a regular aggregate instead of an extension aggregate. An interesting bounding case that has come up in this discussion, but AFAIK is not of interest here. In the second sentence, I think you are thinking of RM 7.6(17.1) which was added in the 2000 revision. But that requirement does not apply to aggregates in assignment statements, and you are right that is not the case we are talking about here. This is the case where an exception occurs during the evaluation of the aggregate, in particular in the call to Initialize there. And this is where we get into whether partially intialized objects are finalized. As I read the rules and understand them, the answer is that to some extent partially initialized objects may have components that have been fully initialized, these must be finalized. We are back to that other comment you made. What you as an author want is that any object that is correctly initialized will be finalized, that any object which is not initialized will not be finalized, and there are no objects in the middle. This is why I like to use an extension aggregate as the first line of an Initialize procedure. If there is an exception raised, Adjust doesn't get called, and I don't have to worry about cascading exceptions. Once the aggregate assignment succeeds I have an object which is not abnormal, in either the Ada technical sense or the practical sense. >>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. And I think it can be--but it won't be. This is one of those complex areas where the permissions in the RM envision an implementation strategy, and no one knows if there is any other way for a compiler to comply with the standard. But there are things which are not required by the language, but even trying to imagine an implementation trying to take advantage of the opportunity to get into trouble is just not going to happen. For example in early days (I think it persisted into Ada82) there were legal Ada source strings where the separation into tokens required semantic information. Of course, if an implementation knew that there were no single character attributes, there was no real problem. Then the scanner/lexer could assume that 'A' was never an attribute followed by an apostrophe, so it was either a character literal or an error. By the time Ada 83 was approved, we had a way to do the scanning of very complex lines without trouble, but still no compiler, AFAIK has ever defined a single character attribute. In this case the wording of 7.6(21) would allow some improper optimizations except for the phrase "...if it can safely create...", so every implementation only does this optimization in a way that is semantically equivalent to the canonical approach. As all this discussion shows, there are cases where the rules lead into grey areas, but in practice there is no grey. As I mentioned above, an implmentation is allowed to have regular aggregates in Ada.Finalization, but aside from that, all values of a controlled type must have been initialized. -- Robert I. Eachus "The only thing necessary for the triumph of evil is for good men to do nothing." --Edmund Burke