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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC 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!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Allocators and exceptions Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH 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> Date: Thu, 13 Sep 2007 09:48:33 +0200 Message-ID: NNTP-Posting-Date: 13 Sep 2007 09:43:19 CEST NNTP-Posting-Host: b77c62d5.newsspool3.arcor-online.net X-Trace: DXC=>R]13a>T0Kk:i=48;n?Z:`McF=Q^Z^V3h4Fo<]lROoRa^;5]aA^R6>b=k>5QV`[:`h[6LHn;2LCVn7enW;^6ZC`dIXm65S@:3>o;DGcRCM]e3` X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:1937 Date: 2007-09-13T09:43:19+02:00 List-Id: On Wed, 12 Sep 2007 17:45:07 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:1bi8swgas8pjl$.1tr7pfyemom8q.dlg@40tude.net... > 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. This need to be fixed. >> 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. Because there is no constructors. One can reject Maciej's idea of rolling everything back, but then the language shall be consistent with un-/partially constructed objects, hence constructors made visible, storage pools visible, etc, in order to manually roll a failed initialization back and then to deallocate. Otherwise, it shall not allow such objects. The second choice *implies* that any exceptions propagating through "new" were illegal, hence converted to Program_Error. The current status is obviously unsatisfactory. As for your concern about efficiency of construction with exceptions. I think that contracted exceptions could fix that nicely. With them Maciej's example: type T (Init : Integer) is record C : Positive := Positive (Init); end record; would become illegal because the default contract of T's constructor will be exception-free. The compiler will reject Positive applied to Init for the component C as potentially raising an unlisted exception. No any roll-back code need to be generated. In rare cases when Constraint_Error exception were indeed the programmer's intention, he could add it to the contract and so the compiler would say - aha, this is what you want, then I will generate roll-back stuff for this. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de