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-Thread: a07f3367d7,97439a4c062cf25d X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.42.141 with SMTP id s13mr10178021qae.3.1368118230416; Thu, 09 May 2013 09:50:30 -0700 (PDT) X-Received: by 10.50.107.98 with SMTP id hb2mr1539780igb.7.1368118230339; Thu, 09 May 2013 09:50:30 -0700 (PDT) Path: y6ni20871qax.0!nntp.google.com!m7no4097660qam.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 9 May 2013 09:50:30 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9038db88-e2b8-43d5-ba19-2d3e1abefa28@googlegroups.com> Subject: Re: User defined type conversion From: Adam Beneschan Injection-Date: Thu, 09 May 2013 16:50:30 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2013-05-09T09:50:30-07:00 List-Id: On Thursday, May 9, 2013 9:12:41 AM UTC-7, Shark8 wrote: > Here's two ways to do it: >=20 > type AB is tagged > record > A, B : Unsigned_16; > end record; >=20 > type abcd is tagged > record > a,b,c,d: Unsigned_8; > end record; >=20 > ---------------------------------------------- >=20 > Function Convert(Input : AB) Return abcd is > -- Note, these records could have dummy variables and layout > -- clauses to exactly match the tagged-record's fields. > type ut_AB is record > A, B : Unsigned_16; > end record; >=20 >=20 > type ut_abcd is record > a,b,c,d: Unsigned_8; > end record; >=20 > Function Convert is new unchecked_conversion > ( source =3D> ut_AB, target =3D> ut_abcd); >=20 > -- Here we overlay the non-tagged record atop the tagged=20 > -- record's fields. >=20 > Working : ut_ab > with import, convention =3D> Ada, address =3D> input.A'Address; > begin > Return Result : abcd do > declare > Result_Subsection : ut_abcd > with Import, Convention =3D> Ada, Address =3D> Result.A'Address; > begin > -- Apply the conversion. > Result_Subsection:=3D Convert(working); > end; > end return; > end Convert; I definitely do not recommend this approach, because it makes some assumpti= ons about how the original tagged records are laid out. The assumption her= e is that aside from whatever data is set aside for tagged records, that th= e remaining fields will be arranged in order, with no gaps between the fiel= ds. Maybe you've found that this is true when using your favorite compiler= on your favorite processor. But Ada was designed to be portable, and it s= addens me a bit that so many of its fans think it's OK to write code that w= orks only for one specific platform, especially when we don't know whether = that's the platform that the OP is using. There are two reasons why these assumptions aren't valid: (1) There are some processors out there that are not byte-addressable. Not= a lot, but there are some. Analog Devices' ADI 21xxx series comes to mind= . When targeting a processor like that, it's entirely possible that the Un= signed_8 fields in ABCD will be allocated one byte per 32-bit word. (2) The compiler vendor may have decided to impose additional alignment req= uirements on fields in tagged types. This one's a stretch, I know. But I = do have vague recollections that the additional semantics of tagged types, = type extensions, and dispatching, sometimes does have an effect on record l= ayout. Anyway, one should **not** make assumptions about how fields are laid out u= nless there's a representation clause laying everything out. And it's norm= ally not a good idea to put a representation clause on a tagged type, in co= de that's supposed to be portable, because you really don't know what a par= ticular implementation may require when it comes to setting aside fields fo= r tagged types. =20 If the OP needs efficiency so badly that some sort of copy operation is abs= olutely needed, then I'd recommend defining *untagged* record types with th= ese fields and with representation clauses, and redefining the tagged types= to have one component whose type is one of these untagged record types. O= nly then would I trust an Unchecked_Conversion or overlay to work correctly= . -- Adam