(Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

(Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[convergence82]

   type Data_Array is array (Num_Types.Mod_4 range 1..8) of
Num_Types.Mod_8;

what's the difference between this and:

   type Data_Array is array (1..8) of Num_Types.Mod_8;

?

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[Georg Bauhaus]

convergence82 wrote:
>    type Data_Array is array (Num_Types.Mod_4 range 1..8) of
> Num_Types.Mod_8;
> 
> what's the difference between this and:
> 
>    type Data_Array is array (1..8) of Num_Types.Mod_8;
> 
> ?

Mod_4 range 1 .. 8 denotes a range of values in type Mod_4.
The index range will be taken from type Mod_4.
1 .. 8 without the Mod_4 denotes a range of numbers from
a "less specific" index type, determined by the rules of
the language -- probably Integer.  The details are found in
and linked from RM 3.6.

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[Robert A Duff]

convergence82 <tiamiata@gmail.com> writes:

>    type Data_Array is array (Num_Types.Mod_4 range 1..8) of
> Num_Types.Mod_8;
>
> what's the difference between this and:
>
>    type Data_Array is array (1..8) of Num_Types.Mod_8;
>
> ?

The index types are different.  The second one is a short-hand for:

    type Data_Array is array (Integer range 1..8) of Num_Types.Mod_8;

It's usually (not always) a bad idea to index an array by a modular
type.  Use a signed integer type.

I think it's poor style to say "1..8" here; I'd spell it out as "Integer
range 1..8" or "Positive range 1..8".  Better yet, declare a new signed
integer type:

    type Index is range 1..8;
    type Data_Array is array (Index) of Num_Types.Mod_8;

- Bob

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[convergence82]

On May 18, 3:36 pm, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:
> convergence82 wrote:
> >    type Data_Array is array (Num_Types.Mod_4 range 1..8) of
> > Num_Types.Mod_8;
>
> > what's the difference between this and:
>
> >    type Data_Array is array (1..8) of Num_Types.Mod_8;
>
> > ?
>
> Mod_4 range 1 .. 8 denotes a range of values in type Mod_4.
> The index range will be taken from type Mod_4.
> 1 .. 8 without the Mod_4 denotes a range of numbers from
> a "less specific" index type, determined by the rules of
> the language -- probably Integer.  The details are found in
> and linked from RM 3.6.

Thanks.  I'm looking at a Ada.Unchecked_Conversion function that
converts from Data_Array_1 to Data_Array_2:

type Data_Array_1 is array (Num_Types.Mod_4 range 1..8) of
Num_Types.Mod_8;
type Data_Array_2 is array (1..8) of Num_Types.Mod_8;

I would think that the way the array is indexed is (integer, mod_4, or
whatever) wouldn't matter (it's the datatype of the elements of the
array that matter).

So, will the convert function really in effect DO NOTHING but copy the
data over?

Steph

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[Adam Beneschan]

On May 18, 12:58 pm, convergence82 <tiami...@gmail.com> wrote:

> Thanks.  I'm looking at a Ada.Unchecked_Conversion function that
> converts from Data_Array_1 to Data_Array_2:
>
> type Data_Array_1 is array (Num_Types.Mod_4 range 1..8) of
> Num_Types.Mod_8;
> type Data_Array_2 is array (1..8) of Num_Types.Mod_8;
>
> I would think that the way the array is indexed is (integer, mod_4, or
> whatever) wouldn't matter (it's the datatype of the elements of the
> array that matter).
>
> So, will the convert function really in effect DO NOTHING but copy the
> data over?

Yes.  In this case, though, a normal type conversion should work.
There's no reason to use Unchecked_Conversion.

                                       -- Adam

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[Georg Bauhaus]

convergence82 wrote:

> Thanks.  I'm looking at a Ada.Unchecked_Conversion function that
> converts from Data_Array_1 to Data_Array_2:

> type Data_Array_1 is array (Num_Types.Mod_4 range 1..8) of
> Num_Types.Mod_8;
> type Data_Array_2 is array (1..8) of Num_Types.Mod_8;

Uhm, converting is what instances of Unchecked_Conversion
do *not* do, in some (paradoxical) sense.
To convert X of type T to X of type D, write D(X).
An instance of Unchecked_Conversion will just leave
the bits unchanged. The programmer should then know the
meaning of the "converted" data.  An Ada array, however,
is a bit more than a sequence of storage cells,
when it includes bounds an other properties of the
corresponding array type.  Hence, arrays of different
type may be stored differenty.

In addition, if you choose "Integer range 1 .. 8" for
the index type (as per Bob's suggestion) the normal
representation of values of type integer may be
different from that of values of type Mod_4.
I imagine that even the instructions generated for indexing
may be different, e.g. indicating different register word
sizes for smaller or larger types. So Unchecked_Conversion
may yield unexpected results.

You can think of Ada arrays as tables where the keys
are values taken from the Index type. The keys will
not be strings, though, but either numbers, or letters,
or enumeration literals.  Maybe this helps to see why
one array is not like the other.


> type Data_Array_1 is array (Num_Types.Mod_4 range 1..8) of
> Num_Types.Mod_8;
> type Data_Array_2 is array (1..8) of Num_Types.Mod_8;
> 
> I would think that the way the array is indexed is (integer, mod_4, or
> whatever) wouldn't matter (it's the datatype of the elements of the
> array that matter).

No, that's not true for Ada arrays. Imagine
some book pages numbered i, ii, iii, iv, ...
while some others are numbered 1, 2, 3, 4, ...
Book printers will carefully observe this difference:
preface, TOC, etc. numbered i, ii, ... and then
the book's "proper text", numbered 1, 2, ...
This difference can be mapped to arrays index types,
reducing the risk of mixing the sequences of book
pages.


> So, will the convert function really in effect DO NOTHING but copy the
> data over?

It shouldn't have to copy at all, that's the point :-)

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[convergence82]

On May 18, 4:53 pm, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:
> convergence82 wrote:
> > Thanks.  I'm looking at a Ada.Unchecked_Conversion function that
> > converts from Data_Array_1 to Data_Array_2:
> > type Data_Array_1 is array (Num_Types.Mod_4 range 1..8) of
> > Num_Types.Mod_8;
> > type Data_Array_2 is array (1..8) of Num_Types.Mod_8;
>
> Uhm, converting is what instances of Unchecked_Conversion
> do *not* do, in some (paradoxical) sense.
> To convert X of type T to X of type D, write D(X).
> An instance of Unchecked_Conversion will just leave
> the bits unchanged. The programmer should then know the
> meaning of the "converted" data.  An Ada array, however,
> is a bit more than a sequence of storage cells,
> when it includes bounds an other properties of the
> corresponding array type.  Hence, arrays of different
> type may be stored differenty.
>
> In addition, if you choose "Integer range 1 .. 8" for
> the index type (as per Bob's suggestion) the normal
> representation of values of type integer may be
> different from that of values of type Mod_4.
> I imagine that even the instructions generated for indexing
> may be different, e.g. indicating different register word
> sizes for smaller or larger types. So Unchecked_Conversion
> may yield unexpected results.
>
> You can think of Ada arrays as tables where the keys
> are values taken from the Index type. The keys will
> not be strings, though, but either numbers, or letters,
> or enumeration literals.  Maybe this helps to see why
> one array is not like the other.
>
> > type Data_Array_1 is array (Num_Types.Mod_4 range 1..8) of
> > Num_Types.Mod_8;
> > type Data_Array_2 is array (1..8) of Num_Types.Mod_8;
>
> > I would think that the way the array is indexed is (integer, mod_4, or
> > whatever) wouldn't matter (it's the datatype of the elements of the
> > array that matter).
>
> No, that's not true for Ada arrays. Imagine
> some book pages numbered i, ii, iii, iv, ...
> while some others are numbered 1, 2, 3, 4, ...
> Book printers will carefully observe this difference:
> preface, TOC, etc. numbered i, ii, ... and then
> the book's "proper text", numbered 1, 2, ...
> This difference can be mapped to arrays index types,
> reducing the risk of mixing the sequences of book
> pages.
>
> > So, will the convert function really in effect DO NOTHING but copy the
> > data over?
>
> It shouldn't have to copy at all, that's the point :-)

Thanks you guys!  Maybe one of the reasons for this awkward use of
Unchecked_Conversion is plain ole "cut-n-paste".  There must be 200+
data types being converted (or more), for the project I am on.  So, I
WILL read your posts more thoroughly in the next day or so.

But for now, thanks for the input,

Steph
PS.  Continued debate is welcome, of course!

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[Adam Beneschan]

On May 18, 1:53 pm, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:
> convergence82 wrote:
> > Thanks.  I'm looking at a Ada.Unchecked_Conversion function that
> > converts from Data_Array_1 to Data_Array_2:
> > type Data_Array_1 is array (Num_Types.Mod_4 range 1..8) of
> > Num_Types.Mod_8;
> > type Data_Array_2 is array (1..8) of Num_Types.Mod_8;
>
> Uhm, converting is what instances of Unchecked_Conversion
> do *not* do, in some (paradoxical) sense.
> To convert X of type T to X of type D, write D(X).
> An instance of Unchecked_Conversion will just leave
> the bits unchanged. The programmer should then know the
> meaning of the "converted" data.  An Ada array, however,
> is a bit more than a sequence of storage cells,
> when it includes bounds an other properties of the
> corresponding array type.  Hence, arrays of different
> type may be stored differenty.

This may be true in theory but I doubt that it is true in practice.
Both array types are constrained; therefore, the representation of the
array is almost certain to be just the eight data elements strung
together.  I doubt that any existing or future Ada compiler is going
to do things any differently, or store the bounds anywhere in the
array data.  Therefore, Unchecked_Conversion is most likely going to
work.  It's a poor idea to use it, though, since a regular Ada type
conversion is legal and is 100% guaranteed to be portable (as opposed
to only 99.9999% guaranteed for Unchecked_Conversion).

A case like this is harder:

type Enum_Type is (E0, E1, E2, E3, E4, E5, E6, E7);
type Data_Array_1 is array (Enum_Type) of Num_Types.Mod_8;
type Data_Array_2 is array (1..8) of Num_Types.Mod_8;

Now an Ada type conversion won't work, and the only way to convert
from one array type to another is to use a FOR loop or an abomination
like
    (1=>A(E0), 2=>A(E1), 3=>A(E2), ...)

                                   -- Adam

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[christoph.grein]

While re-hosting some code, yesterday I bumped into some code like so:

  type Some_Array is array (Some_Index range <>) of Some_Type;
  subtype Small_Array is Some_Array (1 .. 8);
  subtype Max_Array   is Some_Array (1 .. Some_Index'Last);

  function Convert is Unchecked_Conversion (Source => Small_Array,
Target => Max_Array);

Guess what the perpetrator told me was the reason for this
abomination: The compiler complained when he assigned an object of
Small_Array to one of Max_Array. So he found this "solution"...

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[Petter]

For scalar types Checked_Conversion is a good idea:

generic
   type Source is (<>);
   type Target is (<>);

function Checked_Conversion (S : Source) return Target;

with Ada.Unchecked_Conversion;
function Checked_Conversion (S : Source) return Target is
   function "+" is new Ada.Unchecked_Conversion (Source => Source,
                                                 Target => Target);
begin
   declare
      Return_Value : Target := + S;
   begin
      if not Return_Value'Valid then
         raise Constraint_Error;
      end if;
      return Return_Value;
   end;
end Checked_Conversion;

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[christoph.grein]

On May 19, 9:47 am, Petter <petter_frykl...@hotmail.com> wrote:
> For scalar types Checked_Conversion is a good idea:
>
> generic
>    type Source is (<>);
>    type Target is (<>);
>
> function Checked_Conversion (S : Source) return Target;
>
> with Ada.Unchecked_Conversion;
> function Checked_Conversion (S : Source) return Target is
>    function "+" is new Ada.Unchecked_Conversion (Source => Source,
>                                                  Target => Target);

Be careful, a lot can get wrong if the sizes of Source and Target are
different. The 'Valid attribute is not enough.

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[Petter]

ALL compiler warnings must be addressed.

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[Georg Bauhaus]

Petter schrieb:
> ALL compiler warnings must be addressed.

Yes, if they are decisive.

How would you address a parameter that is
not read? Is there a better way than
placing "silencing pragmas" everywhere
(like GNAT's Unreferenced)?

Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)?

[Adam Beneschan]

On May 18, 11:26 pm, christoph.gr...@eurocopter.com wrote:
> While re-hosting some code, yesterday I bumped into some code like so:
>
>   type Some_Array is array (Some_Index range <>) of Some_Type;
>   subtype Small_Array is Some_Array (1 .. 8);
>   subtype Max_Array   is Some_Array (1 .. Some_Index'Last);
>
>   function Convert is Unchecked_Conversion (Source => Small_Array,
> Target => Max_Array);
>
> Guess what the perpetrator told me was the reason for this
> abomination: The compiler complained when he assigned an object of
> Small_Array to one of Max_Array. So he found this "solution"...

Sounds like things should have been set up to use GNAT's --
nouncwoiqtest flag.  This forces the compiler to reject all uses of
Unchecked_Conversion unless the programmer is known to have passed an
IQ test.

Well, if GNAT doesn't have that flag, it should.

                                   -- Adam