From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,31982f45a4d88565 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-05-29 07:25:43 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: A Record Interpretation of an Array Date: Tue, 29 May 2001 10:16:19 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9f0avl$i6q$1@nh.pace.co.uk> References: <3B12C9E0.5E9B06C8@earthlink.net> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 991145781 18650 136.170.200.133 (29 May 2001 14:16:21 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 29 May 2001 14:16:21 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:7841 Date: 2001-05-29T14:16:21+00:00 List-Id: You might want to consider that an Ada implementation might keep dope information about the array in the same vicinity and that this information may not be required by the record. Size & index range info could be kept at the beginning of the array (for runtime checks - although it would likely be at a negative offset from the start of the array so that My_Array'Address yields the first element of the array). The dope information might be considered as part of the array for purposes of assignment. The record type wouldn't need the same info, so it is conceivable in my mind that an unchecked conversion between the two wouldn't work. Obviously, as your disclaimer indicates, this is all going to be extremely implementation dependent and it wouldn't be advisable to rely on such a thing working - especially without representation clauses. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Marc A. Criley" wrote in message news:3B12C9E0.5E9B06C8@earthlink.net... > 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