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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,8acd4291c317f897 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,8acd4291c317f897 X-Google-Attributes: gid103376,public From: Simon Wright Subject: Re: Safety of the Booch Ada 95 Components Date: 1999/12/12 Message-ID: #1/1 X-Deja-AN: 559711218 X-NNTP-Posting-Host: pogner.demon.co.uk:158.152.70.98 References: <1e2lds4.7trgj21rgj9i0N%herwin@gmu.edu> X-Trace: news.demon.co.uk 945011441 nnrp-03:5815 NO-IDENT pogner.demon.co.uk:158.152.70.98 Organization: At Home Newsgroups: comp.lang.ada,comp.lang.c++ X-Complaints-To: abuse@demon.net Date: 1999-12-12T00:00:00+00:00 List-Id: Simon Wright writes: > herwin@gmu.edu (Harry Erwin) writes: > > > In C++, the equate operation for a container class C is preferably > > defined as follows (Sutter, Exceptional C++, Addison-Wesley, 2000): > > > > template > > C& operator=(const C& c) > > { > > if(&c == this) return *this; // not required; done for efficiency > > C temp(c); // uses the copy constructor, may throw > > swap(temp, *this); // swaps the guts of this container with > > // temp. May not throw. > > return *this; // May not throw. > > } // the destructor for temp releases the memory originally in this > > // container, and destructors may not throw > > > > This is strongly exception-safe and exception-neutral, since only the > > copy constructor can throw, and that occurs before the guts are swapped. > > Hence the container remains useable, and no objects are lost from it. > > Now I've been looking at the Booch components for Ada 95, and have > > noticed that the Copy function typically starts by clearing the To > > container. That immediately implies that they are not exception-safe, > > but I'm concerned that they may not be safe under self-assignment as > > well. Is there something about the Ada 95 standard that guarantees that > > there will be no aliasing of container args? [...] > (2) I'm not quite sure what should occur if an exception happened in > the middle of copying a queue; it would be reasonable to expect the > data structure to be uncorrupted, but you couldn't expect any > particular subset of the elements in the queue to have been copied. > > Nevertheless, I need to look at this one .. .. and it seems fine to me, at least for queues. The structure is still valid, though it's not possible to say what the contained values are. Harry sent me private mail to the effect that there do indeed seem to be problems here with the BCs. Well, I don't agree; at least, not that Harry's suggested semantics are any better in practice. The postcondition of HA = HB; seems to be (primed names indicate input values) HB == HB' and (HA == HB' or an exception is raised and HA == HA') In the last case, Harry is going to have to do something about HA, because whatever else it means it does _not_ hold the value it should! Perhaps it contains _last_ month's balance of his bank account, perhaps it's the _old_ state of the helicopter's fuel supply .. The BCs equivalent for assignment is (no warranties, remember) BB == BB' and (BA == BB' or an exception is raised) The above analysis with regard to exceptions holds also for the Copy operation (between queues of the same element type but possibly with different allocation strategies). There is, however, a defect (OK, guys? :-) in the Copy operation, since it fails under self-assignment. Oops. Logged.