Re: A Record Interpretation of an Array

["Marc A. Criley" <mcqada@earthlink.net>]

Keith Thompson wrote:
> 
> "Marc A. Criley" <mcqada@earthlink.net> writes:
>
> > If I wanted to access the contents of this array as a analogous record,
> > I could declare something like:
> >
> >   type Record_View is
> >     record
> >       Field1 : Integer;
> >       Field2 : Integer;
> >       Field3 : Integer;
> >       Field4 : Integer;
> >       Field5 : Integer;
> >     end record;
> >
> > and do an Unchecked_Conversion between the array type and this record
> > type.
> >
> > Is it reasonable to think this conversion (going either way) would give
> > sensible results?  Is there a stronger basis for that answer than a
> > naive "reasonable to think"?
> 
> This will often work, but it's not guaranteed.  In fact, I know of an
> Ada 83 implementation (some versions of TeleSoft's TeleGen2/RISCAda)
> that would reorder record components, even if they're all of the same
> type.  It normally reordered record components to minimize gaps; for
> example, it would try to put components with stricter alignment
> requirements first.  In the initial implementation, it used an
> unstable sort (one that would not maintain the original ordering for
> elements with equal keys -- I think it was a straight Quicksort), so
> your Record_View might be ordered something like Field3, Field5,
> Field2, Field4, Field1.

Since all the array elements/record fields in this pathology are of the
same type (therefore size), there should be no reason for a modern
compiler to reorder them.

> You might have a better chance of getting away with it if you use
> something like "pragma Convention(C, Record_View);".

That can't hurt...

> Of course the most reliable way is to completely specify the layout
> yourself, but then you're overriding the compiler's knowledge of what
> layout is most efficient.

I can't touch the original array declaration, but via ASIS I've got
extensive access to its semantic, and much of its layout, information. 
Utilizing that I can build and constrain the corresponding record's
character.

Marc