Re: Deallocating list of polymorphic objects?

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

"Michael Rohan" <mrohan@ACM.ORG> wrote in message
news:1164930027.758923.119740@h54g2000cwb.googlegroups.com...
...
> I would like to construct a list of polymorphic objects that,
> as part of the list's finalization, deallocates the objects on
> the list.  Basically, I have a vector of pointers to Object'Class.
> The objects are added to the list via procedures defined for
> the list, e.g., append an integer, append a floating point.
> These append procedures allocate objects derived from the
> base Object type for the type being appended, e.g.,
> Integer_Object, which is private to the list package.
>
> Since I want the deallocation to be dispatching, it needs to take an
> access parameter which is then converted to a pointer for the object
> being deallocated, e.g., an Integer_Pointer, and then passed to an
> Unchecked_Deallocation procedure.

To deallocate the elements, then just doing it should work fine:

   procedure Free is new Ada.Unchecked_Deallocation (Object'Class,
Object_Pointer);

Unchecked_Deallocation of the Objects will call Finalize on them, so that
any internal cleanup can be done. (That's presuming that Object is also
derived from Controlled, but IMHO that should be true of virtually all
complex types in new Ada code. Remember that Object can still be abstract
even if derived.) You could also uses a separate "Ready-me-for-Deallocation"
dispatching routine, but that is neither as safe nor fool-proof as just
letting Ada do it: there are special rules in the language that insure that
Finalize is always called at least once.

The important thing here is that (using the terminology of the Ada 2007
predefined containers) the container is responsible for deallocating the
elements as a whole, but any internal cleanup is the responsibility of the
elements themselves. It's not possible (in general) to have objects that
deallocate themselves -- but that's actually a good thing: an object should
be responsible for cleaning its contents up, but only the client can know
how that object is going to be used, and thus how the memory should be
deallocated. Otherwise you have unnecessary coupling between the object and
its clients: the object type cannot be reliably used to declare objects on
the stack (or in the predefined containers, or anywhere that non-standard
storage pools are used, etc.).

Summary: The objects and the list are separate abstractions and should be
kept separate. The list should allocate and deallocation elements (objects);
the objects themselves should do any internal cleanup needed.

                               Randy Brukardt.