Re: Allocators and exceptions

["Randy Brukardt" <randy@rrsoftware.com>]

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