Re: Allocators and exceptions

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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?

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").

> 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?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de