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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6b1a1ed8b075945 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!t8g2000prg.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Allocators and exceptions Date: Tue, 11 Sep 2007 12:21:07 -0700 Organization: http://groups.google.com Message-ID: <1189538467.413193.21430@t8g2000prg.googlegroups.com> References: <1189323618.588340.87180@o80g2000hse.googlegroups.com> <1189524788.300591.312380@w3g2000hsg.googlegroups.com> NNTP-Posting-Host: 85.0.246.232 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1189538468 26269 127.0.0.1 (11 Sep 2007 19:21:08 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 11 Sep 2007 19:21:08 +0000 (UTC) In-Reply-To: <1189524788.300591.312380@w3g2000hsg.googlegroups.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: t8g2000prg.googlegroups.com; posting-host=85.0.246.232; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:1893 Date: 2007-09-11T12:21:07-07:00 List-Id: On 11 Wrz, 17:33, Adam Beneschan wrote: > It sure seemed to me that one could create an example in which, due to > a default initialization on a component that contains a function call > that does some interesting stuff, the automatic reclamation Maciej is > asking for would lead to a dangling reference or something just as > bad. No, there is no such risk. The object that failed to initialized simply does not exist. > Maybe something involving a self-pointer in a limited record > (just to tie it into another thread!). This limited record does not exist. Its presumably dangling self- pointer does not exist, neither. The access to the would-be object is never exposed out of the allocator, so there is no way for anybody else to get the dangling pointer. The possible scenario where it could break could for example involve the pool: the allocator calls Allocate on the pool and there the pool registers the access value somewhere; then the initialization fails, leading to roll-back that includes the call to Deallocate on the same pool. The pool reclaims memory without unregistering the previously exposed access value, leading to dangling pointer. But this is not the problem of the discussed scheme, but rather the problem of the pool - the same problem would happen with regular new +Unchecked_Deallocation. > But I'm still guessing that someone > could come up with an example that shows that this idea won't work. For your information, C++ works like that for as long as it has operator new. If you come up with an example showing that this idea doesn't work and it's not due to artificially broken environment, I will ask you to share your findings widely. Please show me a scheme where the idea breaks, but at the same time where regular new+Unchecked_Deallocation doesn't. -- Maciej Sobczak http://www.msobczak.com/