Prev: FYI -- Lunar lander project relies on SPARK programming language
Next: Simple hack to get $500 to your home
From: Adrian Hoe on 11 Jun 2010 00:26
On Jun 11, 11:14 am, "Jeffrey R. Carter"
<spam.jrcarter....(a)spam.acm.org> wrote:
> You convert between numeric types by using a type conversion:
>
> I : Integer := Integer'Last;
> S : Short_Short_Integer; -- Not portable
> ...
> S := Short_Short_Integer (I);
>
> If the value of I is not within the range of Short_Short_Integer, the conversion
> will raise Constraint_Error.
>
> This is basic Ada, and if it's not what you want, then you should use another
> term than "convert" (and a lengthy explanation of what you're trying to achieve
> and why is probably in order).
>
> --
> Jeff Carter
> "In the frozen land of Nador they were forced to
> eat Robin's minstrels, and there was much rejoicing."
> Monty Python & the Holy Grail
> 70

Sorry for being vague.

I have a number which is in the range of -128..127 and is read as
Integer (32-bit). The reason that I want to convert to
Short_Short_Integer is to save 24 bits of every such value stored in a
record type and to enforce its range on user input. The if..else
statement performs range checking during conversion. As long as the
range is checked, of course, we can use either method: type conversion
as Jeff suggested or use Unchecked_Conversion.

Range_Error is a programmer defined exception and could be redundant
since Ada has already had Constraint_Error. The main purpose of
Range_Error is there to differentiate an exception raised from the
code or Constraint_Error from within the Ada runtime range checking
mechanism. In the event of Range_Error, we will know a value has
fallen out of a defined range and an exception is raised from a
procedure or function.

Which is the preferred method? Short_Short_Integer (I) or
Unchecked_Conversion?

And why Jeff said Short_Short_Integer not portable? Is the
implementation of Short_Short_Integer machine dependent? If
Short_Short_Integer is not portable, what is the best implementation
in your opinion? Convert to a smaller integer to save mere 24 bits or
keep it as 32-bit Integer and perform range checking?

In another similar but different scenario, where a value is in the
range 0..15 and is read as 32-bit Integer. Should I convert to
Unsigned_4?

Where:

type Unsigned_4 is mod 2**4;
for Unsigned_4'Size use 4;

Thanks.
--
Adrian Hoe
From: Jeffrey R. Carter on 11 Jun 2010 03:07
Adrian Hoe wrote:
>
> I have a number which is in the range of -128..127 and is read as
> Integer (32-bit). The reason that I want to convert to
> Short_Short_Integer is to save 24 bits of every such value stored in a
> record type and to enforce its range on user input. The if..else
> statement performs range checking during conversion. As long as the
> range is checked, of course, we can use either method: type conversion
> as Jeff suggested or use Unchecked_Conversion.

Which byte of the 32-bit integer will Unchecked_Conversion return?

> Which is the preferred method? Short_Short_Integer (I) or
> Unchecked_Conversion?

A type conversion is preferred.

> And why Jeff said Short_Short_Integer not portable? Is the
> implementation of Short_Short_Integer machine dependent? If
> Short_Short_Integer is not portable, what is the best implementation
> in your opinion? Convert to a smaller integer to save mere 24 bits or
> keep it as 32-bit Integer and perform range checking?

Implementations are not required to define Short_Short_Integer (or any other
predefined integer type except Integer), so the program may fail on other
compilers. Thus, the use of Short_Short_Integer is not portable.

The best implementation may be influenced by many factors, but the best approach
is to use types defined based on the problem, not predefined types based on the HW.

--
Jeff Carter
"In the frozen land of Nador they were forced to
eat Robin's minstrels, and there was much rejoicing."
Monty Python & the Holy Grail
70
From: J-P. Rosen on 11 Jun 2010 04:59
Jeffrey R. Carter a �crit :
> Implementations are not required to define Short_Short_Integer (or any
> other predefined integer type except Integer), so the program may fail
> on other compilers. Thus, the use of Short_Short_Integer is not portable.
>
But the use of Interfaces.Integer_8 is OK. Guaranteed to be signed
integer on 8 bits, or to be undefined if the machine does not support
such a type - which is a good thing. If you need 8 bit integers and the
machine does not support them, you'd better know ASAP!
--
---------------------------------------------------------
J-P. Rosen (rosen(a)adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
From: Brian Drummond on 11 Jun 2010 08:31
On Fri, 11 Jun 2010 00:07:16 -0700, "Jeffrey R. Carter"
<spam.jrcarter.not(a)spam.acm.org> wrote:

>Adrian Hoe wrote:
>>
>> I have a number which is in the range of -128..127 and is read as
>> Integer (32-bit).
>>... we can use either method: type conversion
>> as Jeff suggested or use Unchecked_Conversion.
>
>Which byte of the 32-bit integer will Unchecked_Conversion return?

Good question. On which machine? :-)

>> Which is the preferred method? Short_Short_Integer (I) or
>> Unchecked_Conversion?
>
>A type conversion is preferred.

And it has no downside. If you need to distinguish between errors here and a
more general "constraint error", it is easy to wrap the conversion in a function
which locally handles "constraint error", and does something appropriate (e.g.
saturates, or raises "range error").

- Brian

From: Maciej Sobczak on 11 Jun 2010 08:28
On 11 Cze, 09:07, "Jeffrey R. Carter" <spam.jrcarter....(a)spam.acm.org>
wrote:

> Implementations are not required to define Short_Short_Integer (or any other
> predefined integer type except Integer), so the program may fail on other
> compilers. Thus, the use of Short_Short_Integer is not portable.

I have seen this argument raised many times already, but it was never
substantiated in terms actual risk estimation.
Could you please list the compilers that do not implement this type?

Or is there somewhere a public list of such incompatibilities?

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: FYI -- Lunar lander project relies on SPARK programming language
Next: Simple hack to get $500 to your home