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: 103376,8acd4291c317f897 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,8acd4291c317f897 X-Google-Attributes: gid109fba,public From: herwin@gmu.edu (Harry Erwin) Subject: Re: Safety of the Booch Ada 95 Components Date: 1999/12/15 Message-ID: <1e2uj35.1hb3ppx1yaa0cgN%herwin@gmu.edu>#1/1 X-Deja-AN: 560967086 References: <1e2lds4.7trgj21rgj9i0N%herwin@gmu.edu> <38512921_3@news1.prserv.net> <3851c7b9_4@news1.prserv.net> <38558788.33C493B@mitre.org> Organization: HDE Associates X-Server-Date: 15 Dec 1999 14:01:53 GMT User-Agent: MacSOUP/2.4.1 Newsgroups: comp.lang.ada,comp.lang.c++ Date: 1999-12-15T14:01:53+00:00 List-Id: Simon Wright wrote: > "Robert I. Eachus" writes: > > > Hyman Rosen wrote: > > > > > Why is an assignment operator that raises an exception broken? > > > > It isn't. But in Ada, an assignment that raises an exception does so > > before actually "copying the bits." > > I don't believe this is true. See LRM 7.6(2). > > > So that objects that were > > consistant are not broken except by an explicit abort from some other > > task while outside an abort-deferred region. However, one explicit > > abort-deferred operation is: "an assignment operation to an object with > > a controlled part." RM9.8(11) There other such operations included so > > that a user of an object of a controlled type can expect that the value > > is never corrupted. > > > > So any user of an Ada package which did corrupt objects in this > > manner would be consider it to be broken. > > Since (LRM 7.6(2)) Adjust is called as the _last_ step of an > assignment, I don't see how the provider of an Ada package can do as > you ask. > > I'm going to do a deep copy. > > I have an object containing a pointer to the value that has been > assigned, so I need to make the deep copy and then put a pointer to > the copy in the current object. > > If that fails, presumably because of memory exhaustion, I can > > (1) make sure that the assignee has a valid but partial copy > > (2) make sure that the assignee has a null pointer > > (3) leave the assignee pointing to the value that has been assigned, > so that the copy isn't deep after all > > (4) not bother > > In *none* of these cases is the assignee "valid". Whether that equates > to being "corrupt" is a question I prefer to leave to the reader .. For comparison, the C++ 98 solution is that the deep copy will throw a bad_alloc exception, and return the memory to the free store. If the deep copy was being done as an initialization step during a constructor, the constructor is unwound, and the bad_alloc exception propagates up. If the deep copy was being done in a different context, the calling routine needs to catch the bad_alloc exception, or it will propagate up. STL containers will be left usable (and for most operations, unchanged and with their iterators still valid). The pointer being assigned to, if it is still in scope after the bad_alloc is caught, will have its original value. If that was corrupt, it will still be corrupt. I teach my students to habitually tie off all pointers so that they either point to valid memory or have the sentinel value of 0, so that delete and delete[] will work correctly. -- Harry Erwin, PhD,