Re: A few Ada questions

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Andrea Taverna wrote on comp.lang.ada:
> I've got a few questions about Ada, generated from discussion
> <h3sln0$rh...@news.eternal-september.org>.
>
> I apologize for my annoying newbieness :D
>
> On 18 Lug, 17:50, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
>
>
> > Andrea Taverna wrote:
>
> > [...]
>
> > > So I have considered these alternatives: FreePascal, Eiffel, Ada and
> > > Modula-3
> [....]
> > > As for memory management (requirement 4), I heard there are different
> > > takes on the matter:
> > >  (a) Ada uses dynamic stack allocation a lot, and in a transparent way,
> > > reducing the need of manual management (MM)
> > >  (b) Ada libraries adopt idioms that further simplifies MM issues
> > >  (c) Conservative garbage collectors such as Bohem's can be used with
> > > Ada, and they are supposed to work "better" with Ada than with unsafe
> > > languages such as C and C++
>
> > I have to add:
> >   (d) controlled types allow you to control allocation and
> > deallocation without a garbage collector.
>
> > > So can MM be said to be easier in Ada than in C? I hope Ada-ers will
> > > mercifully shed some light on the issue.
>
> > Yes, MM is definitely easier in Ada than in C; my experience with
> > Java's garbage collector is that (a) you never learn to manage memory,
> > and (b) is is very easy to run out of memory and get the infamous
> > OutOfMemoryError.  That has never happened to me in Ada, simply
> > because Ada forces me to think about this problem.
>
> > Another reason why Ada is easier than C is because you use pointers
> > only for what they were designed: dynamic allocation and
> > deallocation.  As a consequence, each time you introduce a pointer you
> > naturally think about memory management.  Contrast this to C where
> > simple parameter passing often requires pointers, and with Eiffel or
> > Java where everything is a pointer whether you like it or not.
>
> So I took a deeper look at Ada, and if I'm not mistaken, the MM
> support in Ada boils down to
> 1)  dynamic stack allocation
> 2) malloc/free with Unchecked_Allocation
> 3) Controlled types that allow you implement constructors and
> destructors
> 4) Storage pools.
>
> Apart from (1) and (4), (2) and (3) seem to provide the same
> functionality of corresponding C++ features, with the notable
> exception that (3) requires tagging the type (*).

There are three ways for a type to be controlled: (a) be publicly
tagged and extend Ada.Finalization.Controlled; (b) be privately tagged
and extend Ada.Finalization.Controlled; (c) be untagged and contain a
controlled object.

Here is an example of (b):

with Ada.Finalization;
package P is
   type T is private;
   -- primitive operations here
private
   type T is new Ada.Finalization.Controlled with record ... end
record;
   overriding procedure Initialize (This : in out T);
   overriding procedure Adjust (This : in out T);
   overriding procedure Finalize (This : in out T);
end P;

In this situation, clients can use the type and its primitive
operations but cannot further extend it (compare to a "final" class in
Java).

(c) is more advanced, here is an example:

package P is
   type T is private;
   -- primitive operations here
private
   type Controller (Enclosing : access T) is new
Ada.Finalization.Controlled with null record;
   overriding procedure Initialize (This : in out Controller);
   overriding procedure Adjust (This : in out Controller);
   overriding procedure Finalize (This : in out Controller);

   type T is record -- note: untagged record
     C : Controller (Enclosing => T'Access);
   end record;
end P;

The procedures Initialize, Adjust and Finalize can see their
parameter's enclosing object (and therefore all other components) by
simply dereferencing This.Enclosing.

This pattern is useful for reference counting, among other things.

Note that T *may* be tagged for reasons unrelated to controlledness
and even extend another type.

> As for (4), I couldn't find a practical example of storage pools usage
> on the net, I'd really like to see one.
> The storage pool I have in mind is the one used in ObjC/Cocoa, i.e. a
> storage pool with ref-counted objects. Users can send retain/release
> messages to increment/decrement the pool-allocated object's reference
> count. In which way does this differ from storage pools in Ada?

Ada's storage pools are orthogonal to ref-counted objects.  One
example is in the GNAT run-time library, see:

http://gcc.gnu.org/viewcvs/trunk/gcc/ada/g-debpoo.ads?view=markup

> I know that they have several benefits compared with pool-less
> storage, you can define a homogeneously typed/sized pool improving the
> memory management for associated types, and you can implement MM more
> easily, but, still, the problems I have with MM (at least in C) are :
> - application-specific code is intertwined with MM and vice versa. It
> complicates interfaces and hinders reusability.
> - objects have a graph-like relationship on which MM depends that
> could not be easy to foresee.
> - due to the graph relationship, refactoring MM code, which can ease
> MM itself, gets harder.
> How is Ada supposed to help with this?

I guess you'll have to see for yourself how the combination of
features listed above helps with the problem. However, you still have
to manage memory in Ada; the problem does not magically disappear.

> (*) besides, I infer that  the visibility checks required for
> controlled types exposed at inner levels can be disabled at run-time,
> right?

This is compiler-specific but, in general, yes.

> Finally, I'd have a question about the standard container library. I'm
> probably a bit confused since I've recently been hopping from a
> language to the other, but I saw that Containers do not define
> interfaces and Cursors types are not tagged.
> As such I'm not sure whether I can extend new containers from standard
> ones, including defining new cursors, while having polymorphic
> behaviour.
> For example, can I define a linked-list implemented with an array by
> deriving a standard container?

I'm not an expert on this subject to I'll defer to someone else to
enlighten both of us :)

HTH

--
Ludovic Brenta.