Unchecked_Conversion on different sized types -- problem?

Unchecked_Conversion on different sized types -- problem?

[Mike Silva]

To do some prototyping I'm extending Michael Feldman's ANSI screen package a
bit, to allow colors, etc, and I ran into a question.  I've enumerated
various attributes and set the enumerations to the corresponding ANSI codes,
and I'm using UC to convert the enumerated types to an Integer, to send via
Text_IO.Put().  I get a warning (GNAT 3.12p) that the types for the UC have
different sizes (not surprising), and I'm wondering if UC always does the
"right" thing here, i.e. zero-extending the smaller enum type when
converting to an Integer.

Here are some (reduced) relevant code bits:

type T is ( BLACK, WHITE );

for T use ( BLACK => 30, WHITE => 37 );

function T_to_int is new Unchecked_Conversion( T, Integer );

T_val : T := BLACK;

Text_IO.Put( Item => T_to_int( T_val )...

So, is T_to_int going to give me 30, as opposed to, say, all 32 bits
starting at the address of T_val?  Can somebody tell me where in the LRM it
talks about this?

(It works "as expected" in this case, but I'm wondering what the rules are)

Also, there's not a simpler way to do this that I'm overlooking, is there?

Mike

Re: Unchecked_Conversion on different sized types -- problem?

[reason67]

In article <qXpf4.429$dw3.15200@news.wenet.net>,
  "Mike Silva" <mjsilva@jps.net> wrote:

Adding the following will keep you design and eliminate any potential
errors:

> type T is ( BLACK, WHITE );
>
> for T use ( BLACK => 30, WHITE => 37 );

for T'size use Integer'Size;

> function T_to_int is new Unchecked_Conversion( T, Integer );

---
Jeffrey Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Unchecked_Conversion on different sized types -- problem?

[Bryce Bardin]

Mike Silva wrote:

> type T is ( BLACK, WHITE );
> 
> for T use ( BLACK => 30, WHITE => 37 );

  for T'Size use Integer'Size;

> 
> 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?

  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);

Re: Unchecked_Conversion on different sized types -- problem?

[Mike Silva]

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

Re: Unchecked_Conversion on different sized types -- problem?

[Mike Silva]

Mike Silva wrote in message ...

Disregard the nonsense I just wrote -- I guess I wasn't paying close
attention to what I was responding to.  My *new* response is that such a
translation array just seems like an extra layer, but maybe it is a better
solution than UC.

Mike

>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
>
>
>

Re: Unchecked_Conversion on different sized types -- problem?

[Bryce Bardin]

Mike Silva wrote:
> 
> Mike Silva wrote in message ...
> 
> Disregard the nonsense I just wrote -- I guess I wasn't paying close
> attention to what I was responding to.  My *new* response is that such a
> translation array just seems like an extra layer, but maybe it is a better
> solution than UC.
> 
> Mike
> 
> >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
> >
> >
> >

The purpose of the "extra" layer is to improve efficiency
(by avoiding the cost of repeated format conversion).  Note also
that your solution needs better format control to actually
work, because you don't want to send the leading blanks to the
ANSI terminal:

  Put(..., Width => 0);

Re: Unchecked_Conversion on different sized types -- problem?

[Mike Silva]

Bryce Bardin wrote in message <387E712A.F644BDAC@home.com>...
>...
>The purpose of the "extra" layer is to improve efficiency
>(by avoiding the cost of repeated format conversion).  Note also
>that your solution needs better format control to actually
>work, because you don't want to send the leading blanks to the
>ANSI terminal:
>
>  Put(..., Width => 0);

That's a very good point -- since I'm really only after a T-to-string
representation, there's no reason to have an intermediate integer in this
case.  Forest for the trees...

Mike

Re: Unchecked_Conversion on different sized types -- problem?

[Matthew Heaney]

In article <387E574A.146BD794@home.com> , Bryce Bardin 
<bbardin@home.com>  wrote:

> But why use a representation clause for Color?
>
>   type Color is ( Black, White );
> --  for Color use ( Black => 30, White => 37 );

Better yet, why even use an enumeration type at all?

type Color is new Integer;

Black : constant Color := 30;
White : constant Color := 37;


Matt
--
Evolution is as well documented as any phenomenon in science, as
strongly as the earth's revolution around the sun rather than vice
versa.

Stephen Jay Gould, Time, 23 Aug 1999

Re: Unchecked_Conversion on different sized types -- problem?

[Jim Rogers]

In article <qXpf4.429$dw3.15200@news.wenet.net>,
  "Mike Silva" <mjsilva@jps.net> wrote:
> To do some prototyping I'm extending Michael Feldman's ANSI screen
package a
> bit, to allow colors, etc, and I ran into a question.  I've enumerated
> various attributes and set the enumerations to the corresponding ANSI
codes,
> and I'm using UC to convert the enumerated types to an Integer, to
send via
> Text_IO.Put().  I get a warning (GNAT 3.12p) that the types for the
UC have
> different sizes (not surprising), and I'm wondering if UC always does
the
> "right" thing here, i.e. zero-extending the smaller enum type when
> converting to an Integer.

 The simple solution to this is to declare a set of integer constants,
not enumerated types. The constants will require no conversions at
all.

Jim Rogers
Colorado Springs, Colorado


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Unchecked_Conversion on different sized types -- problem?

[Mike Silva]

Jim Rogers wrote in message <85lht1$l8c$1@nnrp1.deja.com>...
>
> The simple solution to this is to declare a set of integer constants,
>not enumerated types. The constants will require no conversions at
>all.


Let me ask this then:  what value is it to be able to specify the
representation of an enumeration?  It seems to me that when you do this you
always want, at some point, to "get at" the value of an enumeration.  Maybe
the crux of my question (or confusion) is that while enumeration
representations are allowed, there doesn't seem to be any clean way to use
them (assuming that anything called "Unchecked_" isn't "clean").

Mike

Re: Unchecked_Conversion on different sized types -- problem?

[James S. Rogers]

Mike Silva wrote in message ...
>
>Jim Rogers wrote in message <85lht1$l8c$1@nnrp1.deja.com>...
>>
>> The simple solution to this is to declare a set of integer constants,
>>not enumerated types. The constants will require no conversions at
>>all.
>
>
>Let me ask this then:  what value is it to be able to specify the
>representation of an enumeration?  It seems to me that when you do this you
>always want, at some point, to "get at" the value of an enumeration.  Maybe
>the crux of my question (or confusion) is that while enumeration
>representations are allowed, there doesn't seem to be any clean way to use
>them (assuming that anything called "Unchecked_" isn't "clean").
>
>Mike


There is nothing "unclean" about unchecked conversions. Use them as needed,
but use them with care. Uncheccked simply means that you will not get a lot
of
help from the compiler in doing the "right thing". If you convert values
that really
do not map well, the compiler may give you a warning, but will not prevent
you.

My solution was another approach that often ends up being simpler. Sometimes
it is even more efficient. I did not mean to imply that the use of
Unchecked_Conversion
was in any way intrinsically bad.  The use of enumeration representation is
often
useful when you need to follow a communication protocol. When you write the
stream representation of the enumeration value you will get close to the
value
you expect. If you use the GNAT compiler you will get the value you expect.

Jim Rogers
Colorado Springs, Colorado

Re: Unchecked_Conversion on different sized types -- problem?

[Vladimir Olensky]

Unchecked_Conversion gives you a different (type) view of the same object.
So both source and target should be of the same size.

In you case you should have

type T is ( BLACK, WHITE );
for T'Size use 32;                                    -- that was missing in
your code
for T use ( BLACK => 30, WHITE => 37 );


In this case size of T will be equal the size if Integer and your
unchecked coversion will be OK.

Regards,
Vladimir Olensky



Mike Silva wrote in message ...
>To do some prototyping I'm extending Michael Feldman's ANSI screen package
a
>bit, to allow colors, etc, and I ran into a question.  I've enumerated
>various attributes and set the enumerations to the corresponding ANSI
codes,
>and I'm using UC to convert the enumerated types to an Integer, to send via
>Text_IO.Put().  I get a warning (GNAT 3.12p) that the types for the UC have
>different sizes (not surprising), and I'm wondering if UC always does the
>"right" thing here, i.e. zero-extending the smaller enum type when
>converting to an Integer.
>
>Here are some (reduced) relevant code bits:
>
>type T is ( BLACK, WHITE );
>
>for T use ( BLACK => 30, WHITE => 37 );
>
>function T_to_int is new Unchecked_Conversion( T, Integer );
>
>T_val : T := BLACK;
>
>Text_IO.Put( Item => T_to_int( T_val )...
>
>So, is T_to_int going to give me 30, as opposed to, say, all 32 bits
>starting at the address of T_val?  Can somebody tell me where in the LRM it
>talks about this?
>
>(It works "as expected" in this case, but I'm wondering what the rules are)
>
>Also, there's not a simpler way to do this that I'm overlooking, is there?
>
>Mike
>
>
>

Wrap-Up (was Re: Unchecked_Conversion on different sized types -- problem?)

[Mike Silva]

Well, here's what I learned:

1) I can explicitly set the size of enumeration elements to Integer'Size,
avoiding the problem of converting between different-sized objects.

2) I can't even type in the simplest sample code without making a mistake (I
wasn't really using Text_IO.Put to send an Integer...)

3) I didn't think my problem all the way through -- since what I wanted in
the end was an enumeration-to-string mapping, there was no need to deal with
intermediate integers.

4) Enumerations with representation clauses seem to be a little like piggy
banks -- easy to fill, but harder to extract from.

So, my solution is to map an enumeration to an array of strings.  Thanks to
all for your comments.

Mike

Re: Wrap-Up (was Re: Unchecked_Conversion on different sized types -- problem?)

[Matthew Heaney]

In article <qaIf4.469$dw3.16808@news.wenet.net> , "Mike Silva" 
<mjsilva@jps.net> wrote:

> 4) Enumerations with representation clauses seem to be a little like piggy
> banks -- easy to fill, but harder to extract from.

Don't bother using rep clauses for enum types.  Just use an integer
type.


> So, my solution is to map an enumeration to an array of strings.  Thanks to
> all for your comments.


Someone showed how to use Unbounded_String for this.  There are a couple
of other ways:

1) Use static strings:

  A_String : aliased constant String := "this is a test";
  B_String : aliased constant String := "of the emergency";
  C_String : aliased constant String := "broadcast systems";

  type Index_Subtype is (A, B, C);

  type String_Access is access constant String;

  type String_Table is array (Index_Subtype) of String_Access;

  Table : constant String_Table :=
    (A => A_String'Access,
     B => B_String'Access,
     C => C_String'Access);
begin
    ... Table (B).all ...


This avoids heap use.

2) You can use "dynamic" strings, which get allocated statically:

  type Index_Subtype is (A, B, C);

  type String_Access is access constant String;

  type String_Table is array (Index_Subtype) of String_Access;

  Table : constant String_Table :=
    (A => new String'("this is a test"),
     B => new String'("of the emergency"),
     C => new String'("broadcast system"));


The strings are all static, and because they're designated by a
pointer-to-constant string access object, the compilar is smart enough
to do the allocation statically.  This avoids heap use.


Compilar writers: if we use a little function to call the allocator, ie

  function "+" (S : String) return String_Access is
  begin
    return new String'(S);
  end;

  Table : constant String_Table :=
    (A => +"this is a test",
     B => +"of the emergency",
     C => +"broadcast sytsem");
begin

then is the allocation still done statically?

Re: Wrap-Up (was Re: Unchecked_Conversion on different sized types -- problem?)

[Robert A Duff]

"Matthew Heaney" <matthew_heaney@acm.org> writes:

> Compilar writers: if we use a little function to call the allocator, ie
> 
>   function "+" (S : String) return String_Access is
>   begin
>     return new String'(S);
>   end;
> 
>   Table : constant String_Table :=
>     (A => +"this is a test",
>      B => +"of the emergency",
>      C => +"broadcast sytsem");
> begin
> 
> then is the allocation still done statically?

My guess is: Yes, if "+" has a pragma Inline, otherwise no.

- Bob

Re: Unchecked_Conversion on different sized types -- problem?

[Werner Pachler]

I am a little surprised!

As far as i remember UNCHECKED_CONVERSION refused the
unchecked conversion between 2 different sized elements (Ada8x).

Is this new in Ada95?
Is this the new way of "Ada" thinking (to be similar to "C")?

Regards,
Werner

Mike Silva schrieb in Nachricht ...
>To do some prototyping I'm extending Michael Feldman's ANSI screen package
a
>bit, to allow colors, etc, and I ran into a question.  I've enumerated
>various attributes and set the enumerations to the corresponding ANSI
codes,
>and I'm using UC to convert the enumerated types to an Integer, to send via
>Text_IO.Put().  I get a warning (GNAT 3.12p) that the types for the UC have
>different sizes (not surprising), and I'm wondering if UC always does the
>"right" thing here, i.e. zero-extending the smaller enum type when
>converting to an Integer.
>
>Here are some (reduced) relevant code bits:
>
>type T is ( BLACK, WHITE );
>
>for T use ( BLACK => 30, WHITE => 37 );
>
>function T_to_int is new Unchecked_Conversion( T, Integer );
>
>T_val : T := BLACK;
>
>Text_IO.Put( Item => T_to_int( T_val )...
>
>So, is T_to_int going to give me 30, as opposed to, say, all 32 bits
>starting at the address of T_val?  Can somebody tell me where in the LRM it
>talks about this?
>
>(It works "as expected" in this case, but I'm wondering what the rules are)
>
>Also, there's not a simpler way to do this that I'm overlooking, is there?
>
>Mike
>
>
>

Re: Unchecked_Conversion on different sized types -- problem?

[reason67]

In article <85mqht$6sq$1@fleetstreet.Austria.EU.net>,
  "Werner Pachler" <W.Pachler@mobilkom.at> wrote:
> I am a little surprised!
>
> As far as i remember UNCHECKED_CONVERSION refused the
> unchecked conversion between 2 different sized elements (Ada8x).

Depends on the compiler really. I have seen warnings and I have seen
errors in Ada83 in the case of 2 different sizes. I would think that if
the abstraction is "unchecked conversion" then checking size would be a
violation of that abstraction (albeit helpful).
---
Jeffrey Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Unchecked_Conversion on different sized types -- problem?

[Bryce Bardin]

Werner Pachler wrote:
> 
> I am a little surprised!
> 
> As far as i remember UNCHECKED_CONVERSION refused the
> unchecked conversion between 2 different sized elements (Ada8x).
> 
> Is this new in Ada95?
> Is this the new way of "Ada" thinking (to be similar to "C")?
>

It is implementation-dependent.  (Think about truncation and
padding:  which end has the data, what padding bits?)  I don't 
recommend *ever* using UC for different sizes.   

> Regards,
> Werner
> 

Bryce

Re: Unchecked_Conversion on different sized types -- problem?

[Jeff Carter]

In article <qXpf4.429$dw3.15200@news.wenet.net>,
  "Mike Silva" <mjsilva@jps.net> wrote:
> To do some prototyping I'm extending Michael Feldman's ANSI screen
package a
> bit, to allow colors, etc, and I ran into a question.  I've enumerated
> various attributes and set the enumerations to the corresponding ANSI
codes,
> and I'm using UC to convert the enumerated types to an Integer, to
send via
> Text_IO.Put().  I get a warning (GNAT 3.12p) that the types for the
UC have
> different sizes (not surprising), and I'm wondering if UC always does
the
> "right" thing here, i.e. zero-extending the smaller enum type when
> converting to an Integer.
>
> Here are some (reduced) relevant code bits:
>
> type T is ( BLACK, WHITE );
>
> for T use ( BLACK => 30, WHITE => 37 );
>
> function T_to_int is new Unchecked_Conversion( T, Integer );
>
> T_val : T := BLACK;
>
> Text_IO.Put( Item => T_to_int( T_val )...

Text_Io works for Character and String, but not for Integer, so I'm
curious how you get this to work. Perhaps what you want is a conversion
from T to String, and you're using an intermediate Integer value to
obtain this, in which case a set of String constants seems to be the
easiest way to achieve this. Perhaps internally you would like to
declare (assuming a with and use of Ada.Strings.Unbounded)

type Conversion_List is array (T) of Unbounded_String:

Convert : constant Conversion_List :=
(Black => To_Unbounded_String ("30"), ...);

Text_Io.Put (Convert (Formal_Parameter_Of_Type_T) );

and get rid of the representation clause.

>
> So, is T_to_int going to give me 30, as opposed to, say, all 32 bits
> starting at the address of T_val?  Can somebody tell me where in the
LRM it
> talks about this?
>
> (It works "as expected" in this case, but I'm wondering what the
rules are)

ARM 13.9(11) says this is implementation defined.

--
Jeff Carter
"Now go away or I shall taunt you a second time."
-- Monty Python and the Holy Grail


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Unchecked_Conversion on different sized types -- problem?

[Keith Thompson]

"Mike Silva" <mjsilva@jps.net> 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  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Unchecked_Conversion on different sized types -- problem?

[David A. Cobb]

Keith Thompson wrote:
> 
> "Mike Silva" <mjsilva@jps.net> 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  <http://www.ghoti.net/~kst>
> San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
> 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.