Re: Allocators and exceptions

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

"Simon Wright" <simon.j.wright@mac.com> wrote in message
news:m2abrro3f0.fsf@mac.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
> > The "proper" way to handle this is to ensure that default initialize
> > of an object never propagates an exception, and then wrap the
> > allocator properly:
> >
> >     type Access_T is access all T;
> >     procedure Free is new Unchecked_Deallocation (T, Access_T);
> >     function Alloc_Object (...) return Access_T is
> >        A_T : Access_T := new T; -- Default initialized.
> >     begin
> >        A_T.all := <constructor>;
> >        return A_T;
> >     exception
> >         when others => Free(A_T); return null;
> >     end Alloc_Object;
>
> I guess I had misunderstood what's meant by 'constructor', becasue
> this is just what I had in mind ... and there are far worse things to
> leak than memory, such as locks, file handles, data structure
> integrity etc, and those we can handle even in a constructor (ie
> function returning a value of the type rather than a pointer to a new
> value of the type).

The problem with this sort of construction (besides that it is clunky) is
that is doesn't work for limited types without breaking abstraction. OTOH,
the leak in this case doesn't bother me too much, because constructor
failure ought to be rare and it is also rare to be creating a lot of
objects -- so it usually doesn't matter. Moreover, safety critical
applications aren't going to be using allocators in the first place, and
very long-running applications are likely to have problems with memory
fragmentation even if they don't leak any memory -- unless they have a lot
more memory available than they're going to need. Still, the leak is
uncomfortable - it doesn't match Ada's goals.

                 Randy.