Re: Unchecked_Conversion on different sized types -- problem?

["Mike Silva" <mjsilva@jps.net>]

Bryce Bardin wrote in message <387E574A.146BD794@home.com>...
>Mike Silva wrote:
>
>> type T is ( BLACK, WHITE );
>>
>> for T use ( BLACK => 30, WHITE => 37 );
>
>  for T'Size use Integer'Size;

(Slapping head) Yep!

>> function T_to_int is new Unchecked_Conversion( T, Integer );
>>
>> T_val : T := BLACK;
>>
>> Text_IO.Put( Item => T_to_int( T_val )...
>
>> Mike
>
>But why use a representation clause for Color?

Umm, because that's how I would have done it in C? (I know, that carries a
lot of weight here!)  So, as I asked in another reply, why *ever* use a
representation clause for an enumeration?  To me, it's like my key ring:
I've got a CAR_KEY and a HOUSE_KEY, and at some point I want to actually
pass the key's raw data pattern to the lock, and having the raw data pattern
encoded directly in the enumeration seems cleaner than using a 'case'
statement or a translation array.
>
>  type Color is ( Black, White );
>--  for Color use ( Black => 30, White => 37 );
>  type String_Access is access String;
>  Command : array (Color) of String_Access := (new String'("30"), new
>String'("37"));
>begin
>  Text_Io.Put(Command(Color_Val).all);

This seems "busy", but my biggest objection would be having to enter the
same data twice (and keeping both sets consistent) -- isn't that always a
rich source of errors?

Mike