From: Robert Dewar <robert_dewar@my-deja.com>
Subject: Re: Enumeration representation
Date: 1999/09/13
Date: 1999-09-13T00:00:00+00:00 [thread overview]
Message-ID: <7rhkte$na7$1@nnrp1.deja.com> (raw)
In-Reply-To: yeczoyt2hxx.fsf@king.cts.com
In article <yeczoyt2hxx.fsf@king.cts.com>,
Keith Thompson <kst@cts.com> 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.
next prev parent reply other threads:[~1999-09-13 0:00 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-10 0:00 Enumeration representation Alex
1999-09-10 0:00 ` Matthew Heaney
1999-09-10 0:00 ` Robert Dewar
1999-09-10 0:00 ` Keith Thompson
1999-09-11 0:00 ` Robert Dewar
1999-09-11 0:00 ` Keith Thompson
1999-09-12 0:00 ` Bryce Bardin
1999-09-13 0:00 ` Robert Dewar
1999-09-13 0:00 ` Keith Thompson
1999-09-13 0:00 ` Robert Dewar [this message]
1999-09-12 0:00 ` Keith Thompson
1999-09-13 0:00 ` Robert Dewar
1999-09-13 0:00 ` Ted Dennison
1999-09-13 0:00 ` Keith Thompson
1999-09-14 0:00 ` Robert Dewar
1999-09-13 0:00 ` Robert A Duff
1999-09-13 0:00 ` Robert Dewar
1999-09-10 0:00 ` David C. Hoos, Sr.
1999-09-10 0:00 ` Robert Dewar
1999-09-10 0:00 ` Ted Dennison
1999-09-10 0:00 ` Robert Dewar
1999-09-13 0:00 ` Ted Dennison
1999-09-13 0:00 ` Alex
-- strict thread matches above, loose matches on Subject: below --
2004-01-01 20:44 Luke A. Guest
2004-01-01 21:45 ` Stephen Leake
2004-01-01 22:01 ` Luke A. Guest
2004-01-02 1:17 ` tmoran
2004-01-02 1:29 ` Stephen Leake
2004-01-02 3:10 ` Luke A. Guest
2004-01-02 2:46 ` Robert A Duff
2004-01-02 3:12 ` Luke A. Guest
2004-01-02 13:58 ` Marin David Condic
2004-01-02 21:39 ` Pat Rogers
2004-01-03 13:42 ` Marin David Condic
2004-01-03 1:53 ` Robert A Duff
2004-01-02 20:52 ` Randy Brukardt
2004-01-02 21:05 ` Luke A. Guest
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox