Re: User defined type conversion

[Adam Beneschan <adam@irvine.com>]

On Thursday, May 9, 2013 9:12:41 AM UTC-7, Shark8 wrote:
> Here's two ways to do it:
> 
>     type AB is tagged
> 	record
> 	    A, B : Unsigned_16;
> 	end record;
> 
>     type abcd is tagged
> 	record
> 	    a,b,c,d: Unsigned_8;
> 	end record;
> 
>     ----------------------------------------------
> 
>     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;
> 
> 
> 	type ut_abcd is record
> 	    a,b,c,d: Unsigned_8;
> 	end record;
> 
> 	Function Convert is new unchecked_conversion
> 	  ( source => ut_AB, target => ut_abcd);
> 
> 	-- Here we overlay the non-tagged record atop the tagged 
> 	-- record's fields.
> 
> 	Working : ut_ab
> 	  with import, convention => Ada, address => input.A'Address;
>     begin
> 	Return Result : abcd do
> 	    declare
> 		Result_Subsection : ut_abcd
> 		  with Import, Convention => Ada, Address => Result.A'Address;
> 	    begin
> 		-- Apply the conversion.
> 		Result_Subsection:= Convert(working);
> 	    end;
> 	end return;
>     end Convert;

I definitely do not recommend this approach, because it makes some assumptions about how the original tagged records are laid out.  The assumption here is that aside from whatever data is set aside for tagged records, that the remaining fields will be arranged in order, with no gaps between the fields.  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 saddens me a bit that so many of its fans think it's OK to write code that works 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 Unsigned_8 fields in ABCD will be allocated one byte per 32-bit word.

(2) The compiler vendor may have decided to impose additional alignment requirements 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 layout.

Anyway, one should **not** make assumptions about how fields are laid out unless there's a representation clause laying everything out.  And it's normally not a good idea to put a representation clause on a tagged type, in code that's supposed to be portable, because you really don't know what a particular implementation may require when it comes to setting aside fields for tagged types.  

If the OP needs efficiency so badly that some sort of copy operation is absolutely needed, then I'd recommend defining *untagged* record types with these fields and with representation clauses, and redefining the tagged types to have one component whose type is one of these untagged record types.  Only then would I trust an Unchecked_Conversion or overlay to work correctly.

                             -- Adam