Re: Rep Specing Variant Records

[Martin <martin.dowie@btopenworld.com>]

On Sep 17, 3:39 am, Robert Love <rbl...@airmail.net> wrote:
> First, thanks to all who answered my question.
>
> My big concern about the presence of a discriminant in the derived type
> is that I'm shipping the record out via ether net to a C client to
> read.  The C program will not tolerate the extra discriminate.
>
> I have two very similar layouts in the input and output data.  I had
> hoped to use variant records to save me some typing and coding.  I now
> believe I will have to have two complete records, one for input and one
> for output that will have 80% common structure.  Oh, well, it's just
> more typing.
>
> On 2009-09-16 10:03:37 -0500, Adam Beneschan <a...@irvine.com> said:
>
> > On Sep 15, 6:22 pm, R.B. Love <rbl...@airmail.net> wrote:
> >> I want to understand how a variant record gets rep spec'd.  Let's say I
> >> have a sample of my record:
>
> >> type stuff(has_extra:boolean) is
> >> record
> >>     foo: integer;
> >>     bar: integer;
> >>     case has_extra
> >>         when true =>
> >>             blah : float;
> >>         when false =>
> >>             null;
> >>     end case;
> >> end record;
>
> >> for stuff use
> >> record
> >>     foo at 0 range 0..31;
> >>     bar at 4 range 0..31;
> >> end;
>
> >> type normal_stuff is new stuff(has_extra=>false);
> >> type good_stuff is new stuff(has_extra=>true);
>
> >> for good_stuff use
> >> record
> >>     blah at 12 range 0..31;
> >> end record;
>
> >> for normal_stuff'size use 64;  -- 8 bytes
> >> for good_stuff'size use 96;    -- 12 bytes
>
> >> First, does the discriminant take up any size in the record?
>
> > In "stuff", it almost certainly takes space.  If you have a procedure
> > with a parameter X of type "stuff", and that procedure looks at
> > X.Has_Extra, the procedure has to get that data from somewhere, and it
> > will almost certainly get it from some field in X.  The discriminant
> > *could* be passed as a separate parameter, but that would be atypical.
>
> > For your derived types, normal_stuff and good_stuff, whether the
> > discriminant takes space depends on the implementation.  If you didn't
> > put any rep clauses on those types, they would probably have the exact
> > same representation as "stuff" because then type conversions would be
> > implemented just as straight copy operations.  But eliminating the
> > space for the discriminant is also possible.  (By the way, you can't
> > put a rep clause on the derived type under certain circumstances---see
> > 13.1(10)).
>
> >> When I
> >> tried this with a tagged record, I was told that my placement at 0
> >> bytes off set classed with the tag.  That's no good.
>
> > Tagged records are a completely different animal, here.  First of all,
> > you cannot declare a type extension and rearrange any fields
> > (including discriminants) that existed in the parent type; you
> > couldn't get dispatching to work if you were allowed to rearrange
> > those fields.  You can only use a rep clause to rearrange new fields
> > in the type extension.  Second, you definitely can't move the tag to a
> > different place than in the parent type.  That would just blow
> > everything up.
>
> > Finally, although it's theoretically possible to have tags in
> > different places for two different (non-derived) tagged types, it
> > makes implementing the language a lot more difficult.  This is even
> > more true now that interface types have been introduced in Ada 2005.
> > (If you declare a root type Root_Type with a tag in a nonstandard
> > place, and then later "type Child is new Root_Type and Interface_Type
> > with...", then how is an operation on Interface_Type'Class going to
> > know where to find the tag if you give it a Child?)  So it is entirely
> > reasonable for a compiler to insist on the tag being in a set place
> > for every tagged type.
>
> > I don't know what you say this is "no good"---what are you trying to
> > accomplish?  Whatever it is, you're probably going about it wrong.
>
> >> Second, does the layout of normal_stuff look like I expect it would,
> >> that is, the same as stuff?
>
> > If the 'Size clause on Normal_Stuff is legal, then probably not.
> > Stuff has to have room for two integers, a float, and a Boolean; if
> > Integer'Size is at least 16 and Float'Size is at least 32, then
> > Stuff'Size will be larger than 64, which means that the only way
> > Normal_Stuff'Size could be legally 64 would be for the compiler to not
> > allocate space for some fields.  That may mean not allocating size for
> > Blah since it will never exist in a Normal_Stuff anyway.  But when the
> > compiler realizes it will need to rearrange fields, there's no telling
> > what it will do.
>
> > Even if Integer'Size is 16, it's entirely possible that the compiler
> > will allocate 32 bits for Foo and Bar to help with the machine's
> > alignment requirements.  If that's the case, and if it accepts "for
> > Normal_Stuff'Size use 64" as legal, it will need to rearrange things.
>
> > So the answer to your question is "maybe, maybe not".
>
> >> Does the good_stuff record have a complete rep spec?
>
> > I don't know what you mean by this.  The language doesn't require that
> > a rep spec specify every field.  If you don't, the compiler will put
> > the additional fields anywhere it feels like (and not necessarily in
> > the same place where they exist in a Stuff).  So this is a legal rep
> > spec.
>
> >                                        -- Adam
>
>

type A_Common_Part is
   record
      I : Integer;
      F : Float;
   end record;

type An_Input is
   record
      CP : A_Common_Part;
   end record;

type An_Output is
   record
      CP : A_Common_Part;
      C  : Character;
   end record;

Wouldn't that do?

Cheers
-- Martin