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: Simon Wright Subject: Re: Safety of the Booch Ada 95 Components Date: 1999/12/14 Message-ID: #1/1 X-Deja-AN: 560742058 X-NNTP-Posting-Host: pogner.demon.co.uk:158.152.70.98 References: <1e2lds4.7trgj21rgj9i0N%herwin@gmu.edu> <38512921_3@news1.prserv.net> <3851c7b9_4@news1.prserv.net> <38558788.33C493B@mitre.org> X-Trace: news.demon.co.uk 945214231 nnrp-08:26915 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-14T00:00:00+00:00 List-Id: "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 ..