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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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-30 17:55:58 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub.sdsu.edu!newspeer.cts.com!galanthis.cts.com!127.0.0.1.MISMATCH!not-for-mail Sender: kst@king.cts.com Newsgroups: comp.lang.ada Subject: Re: A Record Interpretation of an Array References: <3B12C9E0.5E9B06C8@earthlink.net> From: Keith Thompson Date: 30 May 2001 17:55:57 -0700 Message-ID: X-Newsreader: Gnus v5.5/Emacs 20.3 NNTP-Posting-Host: 209.68.192.180 X-Trace: 991270557 nntp.cts.com 768 209.68.192.180 Xref: archiver1.google.com comp.lang.ada:7903 Date: 2001-05-30T17:55:57-07:00 List-Id: "Marc A. Criley" writes: > 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"? 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. It's quite possible that no current implementation does this. If you decide to depend on that, I suggest that the first thing your code should do is test whether things are laid out as you expect them to be, and raise a fatal exception if they aren't. You might have a better chance of getting away with it if you use something like "pragma Convention(C, Record_View);". 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. -- Keith Thompson (The_Other_Keith) kst@cts.com San Diego Supercomputer Center <*> Cxiuj via bazo apartenas ni.