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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c6e6cdf6ff50e684 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-02-08 08:25:27 PST Path: supernews.google.com!sn-xit-02!supernews.com!isdnet!newsfeed.cwix.com!cpk-news-hub1.bbnplanet.com!news.gtei.net!yellow.newsread.com!netaxs.com!newsread.com!news.harvard.net!not-for-mail From: Steve O'Neill Newsgroups: comp.lang.ada Subject: Re: Representation clause for enumeratives Date: Thu, 08 Feb 2001 11:27:08 -0500 Organization: Avidyne, Inc. Message-ID: <3A82C8DC.1505AC5@avidyne.com> References: <95tqbh$ag7$1@nnrp1.deja.com> <95tre2$f33@news.kvaerner.com> <95u470$ho1$1@nnrp1.deja.com> <95ua6q$mp4$1@nnrp1.deja.com> <3A82BE3F.EB695A73@m_a_i_l.com> NNTP-Posting-Host: 26.avidyne.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: murdoch.harvard.net 981649397 2747 207.180.77.26 (8 Feb 2001 16:23:17 GMT) X-Complaints-To: news@harvard.net NNTP-Posting-Date: 8 Feb 2001 16:23:17 GMT X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf Xref: supernews.google.com comp.lang.ada:5002 Date: 2001-02-08T16:23:17+00:00 List-Id: I'm making an assumption here that you are choosing these enumeration values to match to some hardware encoding. When I have found myself in similar situations in the past I have usually taken a different route. Rather than try to encode the enumeration values (which frequently leads to frustration and maintenance issues) I would instead create an array of appropriately typed objects that are indexed by the enumeration that I was trying to map. I would index into, search through, etc. that array whenever I wanted to convert to/from the external hardware to the internal meaning. It might not seem as elegant or as potentially efficient as assigning the enumeration value directly but in my experience it is a lot less painful. With the proper encapsulation and design metaphor it can actually turn out to be fairly intuitive. Steve O'Neill "M. Kotiaho" wrote: > Robert Dewar wrote: > > > In article <95u470$ho1$1@nnrp1.deja.com>, > > Sandro Binetti wrote: > > > In article <95tre2$f33@news.kvaerner.com>, > > > "Tarjei T. Jensen" wrote: > > > > Have you tried to insert a size directive. e.g > > > > > > > > type TYP_ENUM is (A,B,C); > > > > > > > > for TYP_ENUM'size use 32; > > > > > > Done. But the problem is still the same ... > > > Why? > > > > Presumably a capacity limitation in the compiler you are > > using, not a terribly justifiable one, so you should bring > > this to the attention of the vendor. Most likely the decision > > is to use a signed 32-bit integer to represent enumerations, > > which as you see in this case can be an annoying restriction. > > > > Sent via Deja.com > > http://www.deja.com/ > > Indeed, GNAT on WinNT (Pentium-II) will allow the following: > > type TYP_ENUM is (A,B,C); > > for TYP_ENUM use( > -16#8000000000000000#, > 16#00000002#,------# > 16#7FFFFFFFFFFFFFFF# -- <<<<< NOTICE THIS VALUE !!! > ); > > Apparently, GNAT is using a signed 64-bit integer. > > Incidently, both compilers are sticking to the > "at least" portion of the implementation advice -- they > just define System.Min_Int and System.Max_Int differently: > > (Copied from Lutz Donnerhacke's post) > >Implementation Advice > > 9. The recommended level of support for > enumeration_representation_clauses is: > > 1. An implementation should support at least the internal codes > in the > > range System.Min_Int..System.Max_Int. An implementation need > not > > support enumeration_representation_clauses for boolean types. > > Markku Kotiaho