comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Allocators and exceptions
Date: Thu, 13 Sep 2007 09:48:33 +0200
Date: 2007-09-13T09:43:19+02:00	[thread overview]
Message-ID: <rvb3o7034y9j.opoo2727h04s.dlg@40tude.net> (raw)
In-Reply-To: fc9q08$so5$1@jacob-sparre.dk

On Wed, 12 Sep 2007 17:45:07 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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



  reply	other threads:[~2007-09-13  7:48 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-09  7:40 Allocators and exceptions Maciej Sobczak
2007-09-09 12:17 ` anon
2007-09-09 20:31   ` Maciej Sobczak
2007-09-09 22:43     ` Simon Wright
2007-09-10 12:10       ` Maciej Sobczak
2007-09-10 19:08         ` Simon Wright
2007-09-10  2:56     ` anon
2007-09-10 12:42     ` Dmitry A. Kazakov
2007-09-10 21:48       ` Maciej Sobczak
2007-09-11  9:16         ` Dmitry A. Kazakov
2007-09-11  9:19           ` Maciej Sobczak
2007-09-11 12:27             ` Dmitry A. Kazakov
2007-09-11 19:07               ` Maciej Sobczak
2007-09-11 22:56                 ` Georg Bauhaus
2007-09-12 12:36                   ` Maciej Sobczak
2007-09-12 22:19                     ` Randy Brukardt
2007-09-12  9:32                 ` Dmitry A. Kazakov
2007-09-12 12:42                   ` Maciej Sobczak
2007-09-12 15:25                     ` Dmitry A. Kazakov
2007-09-12 12:29             ` Stephen Leake
2007-09-12 12:46               ` Maciej Sobczak
2007-09-12 20:53                 ` Simon Wright
2007-09-12 22:32                   ` Randy Brukardt
2007-09-12 23:43                     ` Simon Wright
2007-09-13  3:42                       ` Randy Brukardt
2007-09-13  3:36                     ` Randy Brukardt
2007-09-13  9:43                     ` Maciej Sobczak
2007-09-12 22:25                 ` Randy Brukardt
2007-09-13 11:51                 ` Stephen Leake
2007-09-12 14:14               ` Markus E L
2007-09-10 10:37 ` Allocators and exceptions => Read Me First anon
2007-09-10 12:16   ` Maciej Sobczak
2007-09-10 22:10     ` Allocators and exceptions => Trying Again anon
2007-09-10 23:15       ` Markus E L
2007-09-10 15:44 ` Allocators and exceptions Adam Beneschan
2007-09-10 21:58   ` Maciej Sobczak
2007-09-10 22:07   ` Jeffrey R. Carter
2007-09-11  9:14   ` Dmitry A. Kazakov
2007-09-11  9:23     ` Maciej Sobczak
2007-09-11  2:36 ` Randy Brukardt
2007-09-11 15:33   ` Adam Beneschan
2007-09-11 19:21     ` Maciej Sobczak
2007-09-11 21:56     ` Adam Beneschan
2007-09-12  0:34       ` Jeffrey R. Carter
2007-09-12 12:13         ` Maciej Sobczak
2007-09-12 16:34           ` Jeffrey R. Carter
2007-09-12 23:50             ` Jeffrey R. Carter
2007-09-12 12:22       ` Maciej Sobczak
2007-09-12 14:11         ` Markus E L
2007-09-12 16:08         ` Adam Beneschan
2007-09-12 20:35           ` Dmitry A. Kazakov
2007-09-12 21:01             ` Adam Beneschan
2007-09-12 22:45             ` Randy Brukardt
2007-09-13  7:48               ` Dmitry A. Kazakov [this message]
2007-09-12  3:08 ` Allocators and exceptions -- Debugging says memory leak! anon
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox