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.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,eb64de1902329f4f
X-Google-Attributes: gid103376,public
From: George Haddad <george.haddad@lmco.com>
Subject: Re: Record -> Array in Ada
Date: 1996/08/20
Message-ID: <3219E329.18F0@lmco.com>#1/1
X-Deja-AN: 175341802
references: <321991BE.41C67EA6@mailgw.sanders.lockheed.com>
content-type: text/plain; charset=us-ascii
organization: Lockheed Martin M & S, Sunnyvale, CA
mime-version: 1.0
reply-to: george.haddad@lmco.com
newsgroups: comp.lang.ada
x-mailer: Mozilla 2.02 (Macintosh; I; PPC)
Date: 1996-08-20T00:00:00+00:00
List-Id: <comp.lang.ada>


Mike Roske wrote:
> 1) Unchecked_Conversion into a fixed size array.  (And if I do this,
> how do I get the array bounds set correctly?)

   First, if your record contains discriminated, unconstrained arrays, 
be aware that some compilers may include a "dope-vector" _as part of the 
record_.  So, when you get ready to send your record data down the 
"pipe", you can try to "filter" the extra data out or make sure that the 
dope vector is part of your interface specification.  I recommend the 
second (even though it makes your solution less portable), but as 
interface specs are frequently written by hardware types who've no idea 
what "dope vector" means -- except they're fairly certain that it's 
somehow "naughty"  :-) -- that may not be an option for you.

   So, let's pretend for simplicity's sake that we're just dealing with 
unconstrained array types.  You can declare a function which accepts a 
parameter of the unconstrained array type.  Locally this function 
declares a constrained subtype of the parameter's type, _and_ declares a 
constrained subtype of some unconstrained array of 16-bit "things".  You 
can then instantiate Unchecked_Conversion between the two constrained 
subtypes, and pass the result back as a function result of the 
unconstrained 16-bit array type.  Here's an _uncompiled_, _untested_ 
example.

package X is
  type 32_Block is array(INTEGER range <>) of INTEGER;
  -- assume 32-bit INTEGER

  type 16_Block is array (SHORT_INTEGER range <>) of SHORT_INTEGER;
  -- assume 16-bit SHORT_INTEGER

  function Split(This : 32_Block) return 16_Block;
end X;

with Unchecked_Conversion;
package body X is
  Scale : constant SHORT_INTEGER := INTEGER'SIZE / SHORT_INTEGER'SIZE;

  function Split(This : 32_Block) return 16_Block is
    subtype This_Block_Subtype is 32_Block(This'RANGE);
    subtype Return_Subtype is
      16_Block(1..(This'LENGTH * Scale));
    function Convert is
      new Unchecked_Conversion(Source => This_Block_Subtype,
                               Target => Return_Subtype);
  begin   -- Split
    return Convert(This);
  end Split;
end X;

   YMMV.  There will almost certainly be a performance hit, compared to 
the overlay technique, but this general technique (as modified for 
various compiler shortcomings) has worked for me.  And, I've never had a 
problem porting it to new platforms.  (Of course, that may just be the 
platforms I worked on.)  The approach is adaptable to discriminated 
record types (with fully discriminated record subtypes, of course), but 
watch out for those "hidden" inclusions.

   There is one big irritation factor (for me anyway).  Our project is 
one which avoids any of the predefined types.  Anyway, our atomic types 
(like INT_32) are declared in one package, while my communication arrays 
(and their operations) are defined in another.  To avoid Ada array type 
conversion (which is more restrictive and less well implemented on our 
compiler than I'd like), I would like to derive from the array type and 
inherit a Split operation.  _However_, I also may need to (for example) 
checksum the array, so I would like to derive from INT_32 type (avoiding 
the dreaded "use clause"  :-)) to get its arithmetic operations. I know 
of no way in Ada to get a derived array type, composed of derived array 
elements, in a third package.
-- 
I found these opinions on my doorstep, would you please give them a good 
home?