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!news1.google.com!eweka.nl!lightspeed.eweka.nl!195.114.231.69.MISMATCH!feeder.news-service.com!club-internet.fr!feedme-small.clubint.net!news.ecp.fr!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 17:45:07 -0500 Organization: Jacob's private Usenet server Message-ID: References: <1189323618.588340.87180@o80g2000hse.googlegroups.com> <1189524788.300591.312380@w3g2000hsg.googlegroups.com> <1189547814.740732.220140@x40g2000prg.googlegroups.com> <1189599757.106695.147440@57g2000hsv.googlegroups.com> <1189613298.182273.23310@22g2000hsm.googlegroups.com> <1bi8swgas8pjl$.1tr7pfyemom8q.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1189636936 29445 69.95.181.76 (12 Sep 2007 22:42:16 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 12 Sep 2007 22:42:16 +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:1927 Date: 2007-09-12T17:45:07-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1bi8swgas8pjl$.1tr7pfyemom8q.dlg@40tude.net... > On Wed, 12 Sep 2007 09:08:18 -0700, Adam Beneschan wrote: > > > By the way, although I think having the language deallocate the object > > automatically is a bad idea, > > How to reconcile this with: > > 1. objects allocated on the stack > > 2. all sorts of temporal objects the compiler is allowed to create (and > thus allocate somehow, somewhere) > > 3. a permission given to collect garbage? That's the *real* problem: Ada has no such permission when it comes to objects with non-trivial finalization. It is defined precisely where they are going to be finalized, and there is no permission to do it early without an explicit call (which doesn't exist). As it stands, a compiler that does the right thing (in the sense of avoiding a memory leak when it is certain that no reference to the object remain) is actually wrong vis-a-vis the language definition. > Anyway, presuming that the constructor shall clean its mess before > propagating any exceptions, there is no any object here to "deallocate" (I > would say "destroy"). Surely the top-level object's memory was allocated, and there is no place in the language that would ever require Deallocate to be called. Moreover, even a friendly compiler could not do that without violating the language definition. > > I do sympathize with the problem that > > it's impossible to get a hold of the access value that was already > > allocated so that you can do an Unchecked_Deallocation yourself. None > > of the workarounds seem all that good. Unfortunately, I can't think > > of a good way to add this to the language. > > Unchecked_Deallocation may not be called on a pointer to non-constructed > objects. Semantically it is not a pointer at all. It is a raw address on > which Deallocate has to be called. This is indeed a problem. If Ptr is > invalid, then Ptr.all'Address is erroneous. > > A related issue, why on earth "new" is allowed to propagate anything but > Storage_Error or else Program_Error? "new" doesn't propagate anything other than Storage_Error or Program_Error. The initialization expression, OTOH, can propagate anything it wants. Those are separate things from a language perspective; the problem is that you can't *write* them separately. Randy.