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!50g2000hsm.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Allocators and exceptions Date: Mon, 10 Sep 2007 14:58:10 -0700 Organization: http://groups.google.com Message-ID: <1189461490.270038.235840@50g2000hsm.googlegroups.com> References: <1189323618.588340.87180@o80g2000hse.googlegroups.com> <1189439048.467517.186160@19g2000hsx.googlegroups.com> NNTP-Posting-Host: 85.3.208.198 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1189461491 5881 127.0.0.1 (10 Sep 2007 21:58:11 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 10 Sep 2007 21:58:11 +0000 (UTC) In-Reply-To: <1189439048.467517.186160@19g2000hsx.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: 50g2000hsm.googlegroups.com; posting-host=85.3.208.198; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:1869 Date: 2007-09-10T14:58:10-07:00 List-Id: On 10 Wrz, 17:44, Adam Beneschan wrote: > I don't think this can be guaranteed, not as I read 4.8(10). [...] > The message here, > I think, is that the Ada language has said that it doesn't worry about > storage reclamation; you have to worry about that yourself. That's OK for me as long as I'm given necessary tools for this. The problem is that with exceptions I cannot even be sure that I have the access value. Without it "worrying about that myself" is at least challenging. > Anyway, if this is an issue, I'd write a function to perform the "new" > operation. Using your later example: > > function new_T (Init : Integer) return T_Access is > begin > declare > New_Rec : T (Init); > begin > return new T' (New_Rec); > end; > exception > when others => ... > end new_T; OK, so let's complicate it a bit - T is limited. :-) I know that it can be hacked around. I just did not expect Ada to put me in the position that would require hacking something around. > Now any exceptions involved in initializing the record will get caught > before allocation takes place. The allocator itself won't raise any > exceptions (other than Storage_Error), unless copying New_Rec to the > newly allocated object raises an exception, which could happen only if > there are controlled types involved and an Adjust routine raises an > exception, in which case you're in a whole bunch of trouble anyway. Yeah, that's my other disappointment in this area - assignment cannot be made "atomic" in the transactional sense. -- Maciej Sobczak http://www.msobczak.com/