* (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? @ 2009-05-18 19:19 convergence82 2009-05-18 19:36 ` Georg Bauhaus 2009-05-18 19:49 ` Robert A Duff 0 siblings, 2 replies; 14+ messages in thread From: convergence82 @ 2009-05-18 19:19 UTC (permalink / raw) 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; ? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-18 19:19 (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? convergence82 @ 2009-05-18 19:36 ` Georg Bauhaus 2009-05-18 19:58 ` convergence82 2009-05-18 19:49 ` Robert A Duff 1 sibling, 1 reply; 14+ messages in thread From: Georg Bauhaus @ 2009-05-18 19:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-18 19:36 ` Georg Bauhaus @ 2009-05-18 19:58 ` convergence82 2009-05-18 20:50 ` Adam Beneschan 2009-05-18 20:53 ` Georg Bauhaus 0 siblings, 2 replies; 14+ messages in thread From: convergence82 @ 2009-05-18 19:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-18 19:58 ` convergence82 @ 2009-05-18 20:50 ` Adam Beneschan 2009-05-18 20:53 ` Georg Bauhaus 1 sibling, 0 replies; 14+ messages in thread From: Adam Beneschan @ 2009-05-18 20:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-18 19:58 ` convergence82 2009-05-18 20:50 ` Adam Beneschan @ 2009-05-18 20:53 ` Georg Bauhaus 2009-05-18 21:12 ` convergence82 2009-05-18 21:24 ` Adam Beneschan 1 sibling, 2 replies; 14+ messages in thread From: Georg Bauhaus @ 2009-05-18 20:53 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-18 20:53 ` Georg Bauhaus @ 2009-05-18 21:12 ` convergence82 2009-05-18 21:24 ` Adam Beneschan 1 sibling, 0 replies; 14+ messages in thread From: convergence82 @ 2009-05-18 21:12 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-18 20:53 ` Georg Bauhaus 2009-05-18 21:12 ` convergence82 @ 2009-05-18 21:24 ` Adam Beneschan 2009-05-19 6:26 ` christoph.grein 1 sibling, 1 reply; 14+ messages in thread From: Adam Beneschan @ 2009-05-18 21:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-18 21:24 ` Adam Beneschan @ 2009-05-19 6:26 ` christoph.grein 2009-05-19 7:47 ` Petter 2009-05-19 17:53 ` Adam Beneschan 0 siblings, 2 replies; 14+ messages in thread From: christoph.grein @ 2009-05-19 6:26 UTC (permalink / raw) 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"... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-19 6:26 ` christoph.grein @ 2009-05-19 7:47 ` Petter 2009-05-19 8:04 ` christoph.grein 2009-05-19 17:53 ` Adam Beneschan 1 sibling, 1 reply; 14+ messages in thread From: Petter @ 2009-05-19 7:47 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-19 7:47 ` Petter @ 2009-05-19 8:04 ` christoph.grein 2009-05-19 13:13 ` Petter 0 siblings, 1 reply; 14+ messages in thread From: christoph.grein @ 2009-05-19 8:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-19 8:04 ` christoph.grein @ 2009-05-19 13:13 ` Petter 2009-05-19 15:27 ` Georg Bauhaus 0 siblings, 1 reply; 14+ messages in thread From: Petter @ 2009-05-19 13:13 UTC (permalink / raw) ALL compiler warnings must be addressed. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-19 13:13 ` Petter @ 2009-05-19 15:27 ` Georg Bauhaus 0 siblings, 0 replies; 14+ messages in thread From: Georg Bauhaus @ 2009-05-19 15:27 UTC (permalink / raw) 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)? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-19 6:26 ` christoph.grein 2009-05-19 7:47 ` Petter @ 2009-05-19 17:53 ` Adam Beneschan 1 sibling, 0 replies; 14+ messages in thread From: Adam Beneschan @ 2009-05-19 17:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? 2009-05-18 19:19 (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? convergence82 2009-05-18 19:36 ` Georg Bauhaus @ 2009-05-18 19:49 ` Robert A Duff 1 sibling, 0 replies; 14+ messages in thread From: Robert A Duff @ 2009-05-18 19:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-05-19 17:53 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-05-18 19:19 (Num_Types.Mod_4 range 1..8) ------->why not (1..8)? convergence82 2009-05-18 19:36 ` Georg Bauhaus 2009-05-18 19:58 ` convergence82 2009-05-18 20:50 ` Adam Beneschan 2009-05-18 20:53 ` Georg Bauhaus 2009-05-18 21:12 ` convergence82 2009-05-18 21:24 ` Adam Beneschan 2009-05-19 6:26 ` christoph.grein 2009-05-19 7:47 ` Petter 2009-05-19 8:04 ` christoph.grein 2009-05-19 13:13 ` Petter 2009-05-19 15:27 ` Georg Bauhaus 2009-05-19 17:53 ` Adam Beneschan 2009-05-18 19:49 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox