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.9 required=5.0 tests=BAYES_00 autolearn=ham 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!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Allocators and exceptions Date: Wed, 12 Sep 2007 22:42:27 -0500 Organization: Jacob's private Usenet server Message-ID: References: <1189323618.588340.87180@o80g2000hse.googlegroups.com> <1189369871.672082.162750@50g2000hsm.googlegroups.com> <1189460936.295604.143720@r29g2000hsg.googlegroups.com> <1189502377.626510.172690@22g2000hsm.googlegroups.com> <1189601170.835400.72630@w3g2000hsg.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1189654779 13368 69.95.181.76 (13 Sep 2007 03:39:39 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 13 Sep 2007 03:39:39 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Xref: g2news2.google.com comp.lang.ada:1935 Date: 2007-09-12T22:42:27-05:00 List-Id: "Simon Wright" wrote in message news:m2abrro3f0.fsf@mac.com... > "Randy Brukardt" writes: ... > > The "proper" way to handle this is to ensure that default initialize > > of an object never propagates an exception, and then wrap the > > allocator properly: > > > > type Access_T is access all T; > > procedure Free is new Unchecked_Deallocation (T, Access_T); > > function Alloc_Object (...) return Access_T is > > A_T : Access_T := new T; -- Default initialized. > > begin > > A_T.all := ; > > return A_T; > > exception > > when others => Free(A_T); return null; > > end Alloc_Object; > > I guess I had misunderstood what's meant by 'constructor', becasue > this is just what I had in mind ... and there are far worse things to > leak than memory, such as locks, file handles, data structure > integrity etc, and those we can handle even in a constructor (ie > function returning a value of the type rather than a pointer to a new > value of the type). The problem with this sort of construction (besides that it is clunky) is that is doesn't work for limited types without breaking abstraction. OTOH, the leak in this case doesn't bother me too much, because constructor failure ought to be rare and it is also rare to be creating a lot of objects -- so it usually doesn't matter. Moreover, safety critical applications aren't going to be using allocators in the first place, and very long-running applications are likely to have problems with memory fragmentation even if they don't leak any memory -- unless they have a lot more memory available than they're going to need. Still, the leak is uncomfortable - it doesn't match Ada's goals. Randy.