Re: Records that could be arrays

["Steve Whalen" <SteveWhalen001@hotmail.com>]

Dmitry A. Kazakov wrote:
> ... (:-)) Is it C or FORTRAN? I thought nobody uses EQUIVALENCE blocks anymore!
>
> No, the above is not an implementation of two interfaces by the same type.
> It is two overlapped objects of two different types....

I'm not recommending anyone actually use the 'Address overlay, but it
is in Ada for a reason.  A programmer or designer would have to give me
a REAL good reason for doing anything like this in a production system,
and even then I'd probably say no: pick record or array.

About the only way I'd agree to using such code would be if there were
thousands of lines of code that "wanted" to reference a central data
structure as an array, and thousands of lines of code that "wanted" to
reference the same data as a record, but I don't think I've ever seen
this happen in the real world.

But... You said it was an Ada language limitation that you couldn't use
an array as a record and vice versa.  My point is that if it was really
important to do this, you have the option to do a risky implementation
specific overlay and have the expressive power of both array and record
representations. By doing it like in my example, you are documenting
the risky behavior and documenting that you have verified that the
internal representations of the array and the record are identical at
the bit level. And yes, I WANT this kind of trickery to be on a
variable by variable basis, not for an entire class or type of data.

I don't think I'd want Ada to have a facility to do array and record
overlays beyond what exists (in the example I gave), because to me
arrays and records are NOT synonymous. I can't think of a single "real
world" example where the use of the data and the nature of the data in
the application didn't clearly suggest that either it was fundamentally
an array or a record.

I guess that part of the reason I don't want this feature is because I
agree with with Jean-Pierre Rosen's statement that arrays are really
for iterative structures, so I don't see much need for this since most
of the various types of examples given in this thread are clearly (to
me) more safely and properly defined as records.

I don't know that I'd want to burden the compiler with trying to ensure
that an array and record had bit equal representation clauses either
given or implied before allowing such an overlay.  If equal internal
representation is NOT the case, I'd hate to think of the inefficiency
of a program using both "array style" AND "record style" access code
with the compiler having to do a lot of "conversion" of representation
in order to support the hypothesized "overlay" facility.

Ada compilers have enough to keep straight already. Or at least I don't
see enough utility in such a feature to justify the added complexity.
Of course I may be misunderstanding what array/record overlay facility
you have in mind.