Record representation

Record representation

[Martin Dowie]

Is there anything that could be done (quickly ;-) by the ARG for Ada200Y to
do something about this common pain in the *ss?

package Record_Rep is

   type A is record
      I : Integer;
   end record;
   for A'Size use Integer'Size;

   type Index is new Integer range 1 .. 10;

   type AA is array (Index) of A;
   for AA'Size use A'Size * Index'Last;  -- Not allowed!!!!!

end Record_Rep;

Surely the language could be made smart enough to support this? This can be
a real maintenance nightmare to change.

-- Martin

Re: Record representation

[Martin Krischik]

Martin Dowie wrote:

> Is there anything that could be done (quickly ;-) by the ARG for Ada200Y
> to do something about this common pain in the *ss?
> 
> package Record_Rep is
> 
>    type A is record
>       I : Integer;
>    end record;
>    for A'Size use Integer'Size;
> 
>    type Index is new Integer range 1 .. 10;
> 
>    type AA is array (Index) of A;
>    for AA'Size use A'Size * Index'Last;  -- Not allowed!!!!!

You might like to try:

pragma Pack (AA);

or 

for AA'Component_Size use A'Size;

> end Record_Rep;
> 
> Surely the language could be made smart enough to support this? This can
> be a real maintenance nightmare to change.



-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Record representation

[Martin Dowie]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1134178.8pc9pfiqhv@linux1.krischik.com...
[snip]
> You might like to try:
>
> pragma Pack (AA);
>
> or
>
> for AA'Component_Size use A'Size;

Ok, the example was too simple - imagine a record with components that
are arrays, other record etc.

It's a problem I've encountered a few times...

-- Martin

Re: Record representation

[Mark H Johnson]

Martin Dowie wrote:
> Is there anything that could be done (quickly ;-) by the ARG for Ada200Y to
> do something about this common pain in the *ss?
> 
> package Record_Rep is
> 
>    type A is record
>       I : Integer;
>    end record;
>    for A'Size use Integer'Size;
> 
>    type Index is new Integer range 1 .. 10;
> 
>    type AA is array (Index) of A;
>    for AA'Size use A'Size * Index'Last;  -- Not allowed!!!!!
> 
> end Record_Rep;
> 
> Surely the language could be made smart enough to support this? This can be
> a real maintenance nightmare to change.
> 

Let's generalize the situation slightly. What do you suggest be done if 
you change the data type from an Integer to a Natural? Using GNAT on 
x86's, Natural'Size is 31 (not 32) so that would imply setting AA'Size 
to 310 (and not 320) w/ a real pain in the *ss due to packing / 
unpacking of the data.

I remember a private email exchange with Robert Dewar about something 
similar to this a few years ago. Let me see if I can dig up the 
suggestions he had to improve the portability of your code.

   --Mark

Re: Record representation

[Martin Dowie]

"Mark H Johnson" <mark_h_johnson@raytheon.com> wrote in message
news:c2Gxc.1$oX2.0@dfw-service2.ext.ray.com...
> Let's generalize the situation slightly. What do you suggest be done if
> you change the data type from an Integer to a Natural? Using GNAT on
> x86's, Natural'Size is 31 (not 32) so that would imply setting AA'Size
> to 310 (and not 320) w/ a real pain in the *ss due to packing /
> unpacking of the data.

Could use a new attribute 'Object_Size (which would be 32).


> I remember a private email exchange with Robert Dewar about something
> similar to this a few years ago. Let me see if I can dig up the
> suggestions he had to improve the portability of your code.

That would be very interesting - TIA

Cheers

-- Martin

Re: Record representation

[tmoran]

>>   type A is record
>>   type AA is array (Index) of A;
>>   for AA'Size use A'Size * Index'Last;  -- Not allowed!!!!!

>Ok, the example was too simple - imagine a record with components that
>are arrays, other record etc.
  You shouldn't be trying to specify a particular size:  you may get it
wrong (perhaps due to later changes, such as here if Index'First /= 1) and
especially since the compiler may not be capable of generating code to do
it (the A'size=31 previously mentioned).  Pragmas Pack and Component_Size
ought to be able to get the compiler to generate any code it is capable
of, in particular to make AA take as little storage as possible.

------------------
original American ideology:
"War is in fact the true nurse of executive aggrandizement.  In war a
physical force is created, and it is the executive will to direct it.  In
war the public treasuries are to be unlocked, and it is the executive hand
which is to dispense them, In war the honors and emoluments of office are
to be multiplied and it is the executive patronage under which they are to
be employed.  It is in war finally that laurels are to be gathered, and it
is the executive brow they are to encircle.  The strongest passions and
the most dangerous weakness of the human breast - ambition, avarice,
vanity, the honorable or venial love of fame - are all in conspiracy
against the desire and duty of peace."  James Madison

Re: Record representation

[Mark H Johnson]

Martin Dowie wrote:

> "Mark H Johnson" <mark_h_johnson@raytheon.com> wrote in message
> news:c2Gxc.1$oX2.0@dfw-service2.ext.ray.com...
> 
>>Let's generalize the situation slightly. What do you suggest be done if
>>you change the data type from an Integer to a Natural? Using GNAT on
>>x86's, Natural'Size is 31 (not 32) so that would imply setting AA'Size
>>to 310 (and not 320) w/ a real pain in the *ss due to packing /
>>unpacking of the data.
> 
> 
> Could use a new attribute 'Object_Size (which would be 32).
> 
Yes - but its not part of Ada 95. The alternative of course is to create 
a dummy object and then take 'Size of the object instead. We have some 
code that uses that approach - one example follows:

     type Msg_Rec is
        record
           Blah1 : Set.Integer_32;
           Blah2 : Set.Real_15;
        end record;
     type Msg_Rec_Ptr is access Msg_Rec;

     Dummy_Msg_Rec : constant Msg_Rec := (Blah1 => 0, Blah2 => 0.0);

     Msg_Rec_Size : constant Natural := Dummy_Msg_Rec'Size;

The last line being the size to be passed to our messaging system. It 
must be the size of an object, not the size of the type. This type of 
construct (using something like Msg_Rec_Size as a constant) may also 
help in specifying the values you need in your example.

> 
> 
>>I remember a private email exchange with Robert Dewar about something
>>similar to this a few years ago. Let me see if I can dig up the
>>suggestions he had to improve the portability of your code.
> 
> 
> That would be very interesting - TIA
> 
Let's see what I have...

A series of messages related to alignment - not quite sure this is 
exactly the kind of problem you are looking at but I'll post this for 
reference in case it helps.

We have a data type that has 'Size of 400. Note that 400 is not 
divisible by 32. Two years ago, ACT changed the default alignment for 
some data types to 4 (was 1) and broke our code. An example recoded in C 
was [the original Ada has a bazillion comments]...

#include <stdio.h>

struct taxi_select_criteria {
   short c_word;
   char apply_to;
   char starting_at;
   short mask_value;
   char apply_mask;
   char spare;
   } A;

struct select_request {
   struct taxi_select_criteria select_with[6];
   char apply_selection;
   char spare;
   } B;

struct select_request C[10];

int main() {
   printf("Ada size of taxi_select_criteria is %d\n", sizeof(A)*8);
   printf("Ada size of select_request is       %d\n", sizeof(B)*8);
   printf("Ada size of save_taxi_packets is    %d\n", sizeof(C)*8);
   return 0;
}

which should print out the values of 64, 400, and 4000. None of the data 
items are 4 bytes long and I argued (unsuccessfully I may point out) 
that I should not have to specify 'Alignment of taxi_select_criteria nor 
select_request to get the array of select_request fully packed. Let me 
briefly quote part of my argument at the time:

 >[1] Let me look a little bit into the future when "word size" changes 
 >from 4 to 8. If I follow what is stated to its logical conclusion, the 
 >64 bit compiler can reject packed arrays that the 32 bit compiler 
 >accepts. Gnat is not so restrictive - if I add alignment clauses. But 
 >even for gnat - to be portable, I must add those alignment clauses to 
 >every structure that currently fits on a four byte word size and will 
 >not fit on an eight byte word size IF it is [or might be] put into a 
 >packed array. Yet another migration nightmare ahead of many of us.

However, I did get a message about a year ago indicating that the 
alignment rules were relaxed somewhat so the original code might be OK now.

   --Mark

Re: Record representation

[Martin Dowie]

"Mark H Johnson" <mark_h_johnson@raytheon.com> wrote in message
news:27Kxc.5$oX2.2@dfw-service2.ext.ray.com...
> > Could use a new attribute 'Object_Size (which would be 32).
> >
> Yes - but its not part of Ada 95. The alternative of course is to create
> a dummy object and then take 'Size of the object instead. We have some
> code that uses that approach - one example follows:

It's not even Ada0Y! :-)

I was just postulating a new attribute that met my perceived needs.

Re: Record representation

[Martin Dowie]

"Mark H Johnson" <mark_h_johnson@raytheon.com> wrote in message
news:27Kxc.5$oX2.2@dfw-service2.ext.ray.com...
> A series of messages related to alignment - not quite sure this is
> exactly the kind of problem you are looking at but I'll post this for
> reference in case it helps.

Yes, that's the sort of thing - my original array example was a bad
choice but I had just started writing the post when I became pressed
for time. Should have given up and started again later.

Cheers

-- Martin

Re: Record representation

[Stephen Leake]

"Martin Dowie" <martin.dowie@baesystems.com> writes:

> Is there anything that could be done (quickly ;-) by the ARG for Ada200Y to
> do something about this common pain in the *ss?
> 
> package Record_Rep is
> 
>    type A is record
>       I : Integer;
>    end record;
>    for A'Size use Integer'Size;
> 

     Max_Index : constant := 10;

>    type Index is new Integer range 1 .. 10;

     type Index is new Integer range 1 .. Max_Index;
> 
>    type AA is array (Index) of A;
>    for AA'Size use A'Size * Index'Last;  -- Not allowed!!!!!

     for AA'Size use A'Size * Max_Index;

> end Record_Rep;
> 
> Surely the language could be made smart enough to support this? This can be
> a real maintenance nightmare to change.

If Ada doesn't let you do it, there is a better way :).

On the other hand, I agree it would be nice if Index'Last were static
in this instance. But 'Last can't be static in general, so it's
reasonable for it to be never static.

-- 
-- Stephe

Re: Record representation

[Randy Brukardt]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
...
> >    type AA is array (Index) of A;
> >    for AA'Size use A'Size * Index'Last;  -- Not allowed!!!!!
>
>      for AA'Size use A'Size * Max_Index;

The trouble here is that A'Size is not static (A being a composite type);
Index'Last *is* static. So you've solved the wrong problem. :-)

                Randy.

Re: Record representation

[Randy Brukardt]

"Martin Dowie" <martin.dowie@baesystems.com> wrote in message
news:40c6d3d1$1_1@baen1673807.greenlnk.net...
> Is there anything that could be done (quickly ;-) by the ARG for Ada200Y
to
> do something about this common pain in the *ss?
>
> package Record_Rep is
>
>    type A is record
>       I : Integer;
>    end record;
>    for A'Size use Integer'Size;
>
>    type Index is new Integer range 1 .. 10;
>
>    type AA is array (Index) of A;
>    for AA'Size use A'Size * Index'Last;  -- Not allowed!!!!!
>
> end Record_Rep;
>
> Surely the language could be made smart enough to support this? This can
be
> a real maintenance nightmare to change.

While I've had this problem myself, it occurs mainly because of an abuse of
the language (or not trusting compilers to do the right thing). The
important point is that 'Size on a composite type is not supposed to change
the sizes of the components (see 13.3(53)), so it really only can be a
confirming specification - not very interesting. Hardly worth changing the
language over.

When I've had this problem, I'll generally declare appropriate constants:

package Record_Rep is

   type A is record
      I : Integer;
   end record;
   A_SIZE : constant := Integer'Size; -- Usually more complex than this!
   for A'Size use A_SIZE;

    type Index is new Integer range 1 .. 10;

    type AA is array (Index) of A;
    for AA'Size use A_SIZE * Index'Last;  -- Fine.

end Record_Rep;

                    Randy.

Re: Record representation

[Martin Dowie]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:TfGdnTVBHqyzZlrd4p2dnA@megapath.net...
> "Martin Dowie" <martin.dowie@baesystems.com> wrote in message
> news:40c6d3d1$1_1@baen1673807.greenlnk.net...
> > Is there anything that could be done (quickly ;-) by the ARG for Ada200Y
> to
> > do something about this common pain in the *ss?
> >
> > package Record_Rep is
> >
> >    type A is record
> >       I : Integer;
> >    end record;
> >    for A'Size use Integer'Size;
> >
> >    type Index is new Integer range 1 .. 10;
> >
> >    type AA is array (Index) of A;
> >    for AA'Size use A'Size * Index'Last;  -- Not allowed!!!!!
> >
> > end Record_Rep;
> >
> > Surely the language could be made smart enough to support this? This can
> be
> > a real maintenance nightmare to change.
>
> While I've had this problem myself, it occurs mainly because of an abuse
of
> the language (or not trusting compilers to do the right thing). The
> important point is that 'Size on a composite type is not supposed to
change
> the sizes of the components (see 13.3(53)), so it really only can be a
> confirming specification - not very interesting. Hardly worth changing the
> language over.
>
> When I've had this problem, I'll generally declare appropriate constants:


Randy,

Thanks for that - this looks like the pick of the bunch.

It is down to not trusting compilers but the problem I've had at many sites
is coding standards that mandate this practise for always having 'Size
clauses and that are set in stone. :-(

Cheers

-- Martin