From 2093597919409739492 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,96a8c01f7043c2d9 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-09-26 13:36:46 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: francis.glassborow@ntlworld.com (Francis Glassborow) Newsgroups: comp.std.c++ Subject: Re: Proposal: exception stack unwinding resumption Date: Thu, 26 Sep 2002 20:36:45 +0000 (UTC) Organization: Southfield Microcomputer SS Lines: 67 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <6df0c6a8.0208260746.633710cb@posting.google.com> <23b84d65.0209161107.23bea618@posting.google.com> <6df0c6a8.0209170602.2cb54634@posting.google.com> <6df0c6a8.0209201925.6faa9e57@posting.google.com> <6df0c6a8.0209230602.2aba3ca8@posting.google.com> <6df0c6a8.0209240716.6fb5ec00@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed X-Trace: mail2news.demon.co.uk 1033072605 28776 10.0.0.1 (26 Sep 2002 20:36:45 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 26 Sep 2002 20:36:45 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 17ufNL-0007Tz-00 for mail2news@news.news.demon.net; Thu, 26 Sep 2002 20:36:43 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id GAA04954; Fri, 27 Sep 2002 06:36:09 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ncar.ucar.edu X-Reply-To: Francis Glassborow X-Newsgroups: comp.std.c++ X-User-Agent: Turnpike/6.01-U () X-MailScanner: PASSED (v1.2.6 68713 g8QINjRe085155 mailbox2.ucsd.edu) Xref: archiver1.google.com comp.std.c++:14235 In article , Bob Bell writes >> I'd like to be corrected if I'm wrong, but I'm quite certain that if >> ~A() throws, all its data members and base classes are destructed. The >> relevant clause, I believe, is 15.2, where it is said that partially >> constructed objects will have their fully constructed parts destroyed >> properly. It even mention that it works for arrays. > >I don't have a copy of the standard, but I'll give you my >understanding of the language. Perhaps someone else who does have the >standard can settle this for us. > >"Partially constructed objects" refers to exceptions that are thrown >by a constructor, not a destructor. The intent is for the language to >guarantee that objects the programmer cannot access are destroyed >(since the object has not yet finished constructing, the programmer >has not been able to obtain a reference to it). > >If an exception is thrown from some function that is _not_ a >constructor, then only stack objects are destroyed. Therefore, if >A::~A above throws, since the B part is not a stack object, B::~B will >not be called. > >I'd be interested in anybody else's opinion on this as well. I just >ran a quick test in CodeWarrior 7, and it seems to agree with my >interpretation. I am not sure that the Standard actually deals with this. There quite a number of corner problems with dtors which matter not at all until people want to push the boundaries. But it matters not, because supposing that the base subobject dtors are called all they do is make matters worse by ensuring that you have a ghost object with some of its limbs missing. However I have just looked up the requisite part of the C++ Standard. 15.2 para 2 starts: An object that is partially constructed or partially destroyed will have destructors executed for all of its fully constructed subobjects, that is, for subobjects for which the constructor has completed execution and the destructor has not yet begun execution. That makes it quite clear either CodeWarrior got it wrong or your test is faulty. Note that the above requirement means that you could not even resurrect the object as most of it is gone. I suppose that you could place any pointers to any unreleased resources into container somewhere for latter handling. But you could do that anyway without propagating an exception out of a dtor. I maintain that any dtor that _needs_ to throw is perverting the semantics of destructors. If it does not need to throw then it should not do so under any circumstances. -- Francis Glassborow ACCU 64 Southfield Rd Oxford OX4 1PA +44(0)1865 246490 All opinions are mine and do not represent those of any organisation --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]