Re: Thanks Tucker, It works !!!

[tmoran@bix.com]

> But I had to do it with an access type per design requirements.
The example is a Patriot missile to shoot down a fly.  One trusts
there's a reason for this complexity in the actual app.

> I still don't really understand the aliased, all, and access
> keywords working together to allow this sort of C-like pointer
Here's one attempt at an explanation:

  Your Object contains, among other things (eg, abc) a set of 100
pointers to variable sized arrays of integers.  These arrays are not
created dynamically by 'new' allocators, but are in fact aliases of
ordinary arrays declared statically (eg xyz5_array), thus allowing
'back door' access to those arrays and the resulting maintenance,
optimization, storage/register placement etc problems of things that
can be read or written directly (xyz5_array(3) := 17;) or indirectly
(This.XYZ(1).all(3) := 17;).  The key word 'aliased' gives warning to
the compiler and the maintainer that such shenanigans are going on
with xyz5_array.

  Usually, access types point to things dynamically allocated on the
heap with 'new'.  But your type "xyz_array_pointer" may in fact point
to something allocated on the stack, like xyz5_array, as well.  The
keyword 'all' tells the compiler and the maintainer this vital fact
about xyz_array_pointer.

  An Ada 83 access type only pointed to heap-allocated objects, so it
didn't have 'all' or 'aliased'.  Basically, to make your program run
in Ada 83, you would have to simplify it by dropping those key words
and the line
  xyz5_array : aliased xyz_array := (1..5 => 0);
and changing
  This.XYZ(1) := xyz5_array'ACCESS;  -- address of xyz5_array is assigned
to
  This.XYZ(1) := new xyz_array'((1..5 => 0)); -- an xyz5 array is created

  Your next question, should you choose to continue this task, will
probably be about the error messages you get when forgetting about the
lifetime problems of pointers to things that disappear when the stack
is popped on return from a subprogram.