Re: Type in allocator has deeper level than designated class-wide type

[Adam Beneschan <adam@irvine.com>]

On Jun 14, 7:04 pm, Adrian Hoe <aby...@gmail.com> wrote:
> On Jun 15, 12:01 am, Adam Beneschan <a...@irvine.com> wrote:
>
>
>
>
>
> > On Jun 14, 1:01 am, Adrian Hoe <aby...@gmail.com> wrote:
>
> > > But this defeats my implementation intention which the size and the
> > > type of its data array can only be determined during runtime. Any
> > > suggestion?
>
> > There was no reason to change the generic parameters to High_Cloud, or
> > to change the type of the Data component from Data_Array to Item.  As
> > I tried to explain, your problem had nothing to do with arrays.  The
> > problem has to do with where the Element_Record type extension is
> > declared, which has to do with where the High_Cloud generic is
> > instantiated.  In your latest example, you instantiated it directly in
> > a library package, Hen, so there won't be a problem.  If you
> > instantiate it inside a procedure, there will be a problem.  But the
> > types of the components don't matter.
>
> > If it *does* make a difference---i.e. if declaring Data as a
> > Data_Array instead of an Item makes things fail, even if High_Cloud is
> > still instantiated directly inside Hen---then I believe the problem is
> > with your compiler, and you need to contact your compiler vendor and
> > file a bug report.
>
> >                                   -- Adam
>
> Yes, of course both methods are working as long as the instantiation
> happens at library level. The implementation of I_Array (e.g.
> I_Array_31 to indicate array (1..31) of Integer) in Hen gives the
> array a name to describe it, rather than Data_Array as in High_Cloud
> in the 1st post.
>
> Compiler  error has been ruled out.
>
> Is there any other method other than using "generic" package? Again,
> the rule is: The data type and the size of the array can only be
> determined during runtime.

OK, I wasn't really clear on your requirements.  (Mostly I was trying
to solve your legality issue.)

If just the size had to be determined during runtime, I'd suggest
using a discriminant record with the size as the discriminant; you
could define "Data" as an array whose bound depends on that
discriminant (and get rid of the generic formal parameter N).  More
specifically:

   type Data_Array is array (Positive range <>) of Item;

   type Element_Record (N : Positive) is new List.Node with
       record
          Name : Unbounded_String;
          Color : Unbounded_String;
          Data  : Data_Array (1 .. N);
       end record;

But I'm not sure what you mean by "the data type is determined at
runtime".  In the solution you're trying to use, you instantiate
High_Cloud with the upper bound and an Item type, and apparently
you're instantiating it inside a procedure.  But although the upper
bound "N" may be something you have to compute inside the procedure,
in most cases the Item type should be something that can be defined
outside the procedure.  In one of you examples, you seemed to use
Integer for the Item type.  This means that if you get rid of the
generic formal parameter N and make it a record discriminant, as I
explained above, you can then instantiate High_Cloud with Item =>
Integer *outside* the procedure, and then you can still have an
Element_Record whose size depends on values you define inside the
procedure, but since the type is actually defined outside the
procedure, you won't have the access type violation problems.  (Note:
I have not tried this.  I think it will work.)

Hopefully that should be enough to solve your problem.  But if you
still think that the "data type" has to be defined inside the
procedure, you'll need to give an example that demonstrates why.  Ada
doesn't really have the ability to construct new types at runtime.

                                 -- Adam