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, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c9f437cff8842e X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Enumeration representation Date: 1999/09/13 Message-ID: <7rhkte$na7$1@nnrp1.deja.com>#1/1 X-Deja-AN: 524267448 References: <37D8E3BC.175DB72C@newtech.it> <7rcceh$anh$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x27.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Mon Sep 13 01:44:16 1999 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-09-13T00:00:00+00:00 List-Id: In article , Keith Thompson wrote: > I still think that enumeration representation clauses, as currently > defined, are more trouble than they're worth. I definitely agree, and they have a very nasty implementation dependence, namely whether arrays with this index type have holes or not (the RM does not specify). I personally spent a > great deal of time implementing them in TeleSoft's old Ada compiler -- > and never used them outside a test program. Surprisingly they are often used, but I suspect that in many cases where they are used, it would be fine to use a C style enumeration, i.e. an integer type with a bunch of constant definitions. If the definition hadn't > gone to quite so much trouble to make them (nearly) invisible, they > might have been more useful -- for example, by providing predefined > attributes to convert between an enumeration value and its internal > representation. Well it is easy enough to use unchecked conversion Even an attribute that gives an integer type > guaranteed to be Unchecked_Conversion-compatible with a given > enumeration type would have helped, in a ugly sort of way. (I'm > assuming such a type has to be of the same size and signedness as the > (internal representation of the) enumeration type. It's easy enough to define the type you need ... Unless the > semantics of Unchecked_Conversion between discrete types of different > sizes are well-defined -- I've never been quite clear on that point.) No, the sizes should be the same, but this is easy enough to arrange. In GNAT everything is fine if sizes are different, you just get the equivalent of a type conversion without any checks, but not all compilers (and certainly not the RM) guarantee this. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.