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: "David A. Cobb" Subject: Re: Unchecked_Conversion on different sized types -- problem? Date: 2000/01/16 Message-ID: <38824804.C61D9335@home.com>#1/1 X-Deja-AN: 573510660 Content-Transfer-Encoding: 7bit References: X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 948062212 24.10.108.106 (Sun, 16 Jan 2000 14:36:52 PST) Organization: @home MIME-Version: 1.0 NNTP-Posting-Date: Sun, 16 Jan 2000 14:36:52 PST Newsgroups: comp.lang.ada Date: 2000-01-16T00:00:00+00:00 List-Id: Keith Thompson wrote: > > "Mike Silva" writes: > [...] > > type T is ( BLACK, WHITE ); > > > > for T use ( BLACK => 30, WHITE => 37 ); > > Enumeration representation clauses are, in my opinion, a poorly > designed feature of the language. The idea of assigning a numeric > value to each element of an enumeration type is potentially useful, > but the lack of a well-defined way to use get at the representation > makes it nearly useless in most applications. > > When Ada 83 was originally designed, it was intended that a > representation clause should have as little effect as possible on the > behavior of a type; it's the compiler's responsibility to generate > code that "hides" the representation. In this case, I think the > language designers hid the representation too well. During the Ada 95 > design, I think it was felt that enumeration representation clauses > weren't used often and thus weren't worth fixing. (I'm probably > horribly misrepresenting the intent of the designers of both Ada 83 > and Ada 95; feel free to jump in and correct me.) > > With the addition of a couple of predefined attributes, similar to > 'Val and 'Pos but operating on the underlying representation rather > than on position numbers, enumeration representation clauses could > have been far more useful. GNAT's 'Enum_Rep attribute provides part > of this, but of course any code that uses it is non-portable. > > -- > Keith Thompson (The_Other_Keith) kst@cts.com > San Diego Supercomputer Center <*> > Welcome to the last year of the 20th century. I wasn't there, but I recall reading that representation clauses were considered necessary by the embedded system folks because the representation might be dictated by the hardware. Consider a status enumeration for an i-o device. Still, there's no way to make it pretty. I've seen a lot of stuff where enumeration seems the appropriate abstraction but they get all hung up because the enumeration requires that ALL states be known to the package that declares the type. IMNSHO, the way out is a private type with the various states represented by functions. As I recall, in a weird way the RM specifies that references to the enum.value THIS are syntactically identical to references to a 'Function This returns Enumerated_Thing;' The critical thing about enumerated types is that they define an ORDERING. It is well defined to talk about ENUM_VAL_A < ENUM_VAL_B. In is NOT particularly well defined to talk about 'if Device_State > Ready . . .' --------------------- A rusty practitioner.