comp.lang.ada
 help / color / mirror / Atom feed
From: "Marc A. Criley" <mcqada@earthlink.net>
Subject: A Record Interpretation of an Array
Date: Mon, 28 May 2001 22:53:17 GMT
Date: 2001-05-28T22:53:17+00:00	[thread overview]
Message-ID: <3B12C9E0.5E9B06C8@earthlink.net> (raw)

I'll start with disclaimers :-)

I know what I'm going to be asking about is not defined by the language,
is non-portable, is implementation defined, etc.  I'm just looking to
gather some thoughts and opinions here.

Consider a plain, simple, fixed-length array of some type--no variants,
tagged types, unconstrained anythings, packing pragmas or
specifications.  Just your plain 'ole basic array.  For example, an
array (1..5) of Integer.

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"?


What if the array element type was of a record type, whose 'size
indicated an odd number of bytes?  My experience has been that arrays of
such types pad out the elements, and so could one also reasonably expect
the analogous record view to equivalently pad out each such field?


And last, if the array was multi-dimensional (but still statically
constrained), could a record be constructed to correctly overlay that
array?  For example:

  type Array_2_X_4 is array (1..2, 1..4) of Some_Type;

  type Index_2_Elements is
    record
      Field1 : Some_Type;
      Field2 : Some_Type;
      Field3 : Some_Type;
      Field4 : Some_Type;
    end record;

  type Index_1_Elements is
    record
      Field1 : Index_2_Elements;
      Field2 : Index_2_Elements;
    end record;


(In case someone asks, "What problem are you actually trying to solve
here?"  The answer is, to manipulate an array via a record-oriented
approach.  I have a lot of code that does varied and sundry things with
record definitions, and by considering an array as a degenerate case of
a record (the fields are all of the same, rather than different, types),
I can reuse that code to do the exact same kinds of things to arrays
that I already do to records.)

Marc A. Criley



             reply	other threads:[~2001-05-28 22:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-28 22:53 Marc A. Criley [this message]
2001-05-29  3:29 ` A Record Interpretation of an Array Jeffrey Carter
2001-05-29 13:34 ` Ted Dennison
2001-05-29 14:16 ` Marin David Condic
2001-05-31  0:55 ` Keith Thompson
2001-05-31 12:47   ` Marc A. Criley
2001-06-01  1:22     ` Keith Thompson
2001-06-01  0:14 ` Mark
2001-06-01  8:45   ` Ehud Lamm
2001-06-01 12:39   ` Marc A. Criley
2001-06-01 18:20     ` Tucker Taft
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox