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-18 12:32:31 PST Path: archiver1.google.com!news1.google.com!news.glorb.com!logbridge.uoregon.edu!xmission!news-hog.berkeley.edu!ucberkeley!news.cis.ohio-state.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!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: Thu, 18 Mar 2004 14:32:08 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <105k1qt2i88gt1c@corp.supernews.com> References: <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> <3vydndmUiYRplsTdRVn-sQ@comcast.com> <105ieithg52qo74@corp.supernews.com> <1079622255.263633@master.nyc.kbcfp.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:6417 Date: 2004-03-18T14:32:08-06:00 List-Id: "Hyman Rosen" wrote in message news:1079622255.263633@master.nyc.kbcfp.com... > Randy Brukardt wrote: > >>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. > > > > Right, but that's a tough property to guarentee, particularly if you want to > > to be reasonably secure from abort and the like. > > C++ does its best to guarantee this, but will abort the program if, > during the automatic destruction of objects as a result of a thrown > exception, another exception propagates out of one of these destructors. > There's only so much you can do in cases like that. Even Ada raises a > program error in such cases. I was thinking about task abort, which can leave stuff in pretty much any state. You can protect against exceptions, but you can't protect against abort. (With two important exceptions: protected operations and Initialize/Adjust/Finalize routines are abort-deferred.) > But if you write your destructors so that exceptions can never escape > (which is the recommended style, because throwing an exception out of > a function "means" that the function cannot fulfill its duty, whereas > a destructor has no choice in the matter, since the object is being > destroyed regardless of what the destructor thinks about it), then C++ > provides that guarantee - objects are constructed once and any object > which is constructed will be destructed. (Barring manual intervention, > of course.) I think that is true in Ada as well. The question that Robert Eachus is thinking about is what happens if an Initialize routine propagates an exception (or a constructor in C++). In such a case, the object could be partially initialized. Ada says that the top-level finalizer will not be called in that case (although the finalize of controlled components that completed initialization will be called). This also covers abort during initialization (before Initialize is called, since it is abort-deferred). But abort of an assignment can cause an object to end up in a goofy state (say, if it happens between the target finalization and the Adjust). > > I think it is best to depend primarily of a valid flag > > The problem with a valid flag is that it pushes the responsibility for > validity testing out to all the methods. One of the goals of having a > constructor in OO was to localize object construction in one place, so > every other method could assume that the object was in a consistent and > valid state. Not necessarily. What I was thinking of was a flag for the use of Initialize/Adjust/Finalize -- so that Finalize does nothing if it is not set. That's absoletely necessary if you use Robert's aggregate assignment, because Finalize will be called with an object on which Initialize has not run. And it's always possible in the Ada model that Finalize will be called twice. OTOH, any (other) method of the type can assume that the object is valid. (This presumes that Initialize isn't calling methods, but that is under the control of the programmer.) > > (For someone who claims to not know Ada very well, Hyman knows Ada very > > well. He should join the ARG. :-) We could use him.) > > :-) It's mostly that I understand in pretty excruciating detail how > things work in C++ (and in Java, to some extent), and the reasons for > those behaviors. When I see that Ada does something differently, I can > try to figure out whether those reasons will have an effect that C++ > was designed to avoid. (Note that I'm not claiming C++ is better, I'm > just comparing effects of different decisions.) Which was my point. Many ARG members don't know C++ that well, so we may miss subtilies of the design. Your input is very useful that way. It would be especially useful on the new features of Ada 2005 (like interfaces), while we still can repair screw-ups. Randy.