Re: Unconstrained Arrays

[belteshazzar <gbelteshazzar@gmail.com>]

On Mar 21, 1:45 am, Adam Beneschan <a...@irvine.com> wrote:
> On Mar 19, 11:45 pm, sjw <simon.j.wri...@mac.com> wrote:
>
> > There is a deep language-lawyerly reason (which I don't understand)
> > why an array like your My_Array can't be aliased (at any rate in
> > Ada95); you have to use the initialize-with-aggregate approach.
> > Perhaps that's what leads to the initialize-with-aggregate style.
>
> I don't remember what exact rules make this illegal (I could look them
> up, but I don't feel like it right now; it has to do with nominal
> subtypes).  But here's the issue:
>
> Say you declare an array
>
>   type Unconstrained_Array is array (Natural range <>) of Integer;
>   type Unconstrained_Array_P is access Unconstrained_Array;
>   Arr : aliased Unconstrained_Array (1..100);
>
> When you have an object of type Unconstrained_Array_P, it points to a
> specific object with specific bounds, and the code has to have a way
> to get the bounds from the pointer.  In some Ada implementations, the
> way this works is that the bounds of the array are stored in memory
> followed by the array data.  This worked fine in Ada 83, where the
> only way you could get an Unconstrained_Array_P was with an
> allocator.  In Ada 95, we have 'Access and "aliased", so we have to
> consider the possibility that someone would want to use the 'Access of
> Arr as an Unconstrained_Array_P.  In those Ada implementations, this
> would mean that the compiler would have to store the bounds of every
> aliased array in front of the array data, including those that are
> record components, just in case some other part of the code somewhere
> else in the program decided to use the 'Access of it as an
> Unconstrained_Array_P.  This was deemed to be too much overhead, so as
> a compromise the language rules were engineered so that in this case,
>
>   Arr : aliased Unconstrained_Array (1..100);
>
> 'Access could not be used as an Unconstrained_Array_P, while in this
> case:
>
>   Arr : aliased Unconstrained_Array := <initial expression>
>
> it could (and the bounds would have to be stored in memory).  So that
> way,  the programmer has a choice.
>
> I'm sure that things were done in this way to avoid adding too much
> extra language syntax.  If I had been responsible for designing the
> Ada syntax, the language would have already died a horrible death and
> we wouldn't even be having this discussion; nevertheless, I might have
> suggested something like
>
>   Arr : aliased {unconstrained_access_ok} Unconstrained_Array
> (1..100);
>
> with attribute names (that aren't added to the list of reserved words)
> in braces to tell the compiler things whether it's legal to convert
> the 'Access to an unconstrained array pointer.
>
> Hope this helps explain things.  In any case, I strongly agree with
> everyone else that using pointers in the OP's particular situation is
> the wrong approach, and there shouldn't be any reason for it except
> perhaps to work around a poor compiler implementation.
>
>                              -- Adam


I have to say that in my opinion this is a crappy language feature,
unconstrained and constrained arrays of the same type should be
interchangeable when declared on the stack. I realise that Ada05
allows the <> initialiser but i see that as a pretty poor solution.

we've converted our system to not use handles and it is so much
cleaner. the only problem is that for no-optimisation compilation
(used for debugging) it seems that the compiler is copying the large
arrays around. personally i don't see that as a problem.

thanks for everyone's help.