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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7e29322ee367c19d X-Google-Attributes: gid103376,public From: "Mike Silva" Subject: Re: Unchecked_Conversion on different sized types -- problem? Date: 2000/01/13 Message-ID: #1/1 X-Deja-AN: 572323639 References: <387E574A.146BD794@home.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Complaints-To: news@wenet.net X-Trace: news.wenet.net 947805519 206.169.137.33 (Thu, 13 Jan 2000 15:18:39 PST) NNTP-Posting-Date: Thu, 13 Jan 2000 15:18:39 PST Newsgroups: comp.lang.ada Date: 2000-01-13T00:00:00+00:00 List-Id: 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