From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!y20g2000vbk.googlegroups.com!not-for-mail From: Martin Newsgroups: comp.lang.ada Subject: Re: Rep Specing Variant Records Date: Thu, 17 Sep 2009 01:25:19 -0700 (PDT) Organization: http://groups.google.com Message-ID: <7ba04f56-6b57-437d-bf38-309d2dbb4b21@y20g2000vbk.googlegroups.com> References: <2009091520225816807-rblove@airmailnet> <2009091621390916807-rblove@airmailnet> NNTP-Posting-Host: 20.133.0.8 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1253175920 31336 127.0.0.1 (17 Sep 2009 08:25:20 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 17 Sep 2009 08:25:20 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: y20g2000vbk.googlegroups.com; posting-host=20.133.0.8; posting-account=g4n69woAAACHKbpceNrvOhHWViIbdQ9G User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3,gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:8358 Date: 2009-09-17T01:25:19-07:00 List-Id: On Sep 17, 3:39=A0am, Robert Love 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. =A0The C program will not tolerate the extra discriminate. > > I have two very similar layouts in the input and output data. =A0I had > hoped to use variant records to save me some typing and coding. =A0I now > believe I will have to have two complete records, one for input and one > for output that will have 80% common structure. =A0Oh, well, it's just > more typing. > > On 2009-09-16 10:03:37 -0500, Adam Beneschan said: > > > On Sep 15, 6:22=A0pm, R.B. Love wrote: > >> I want to understand how a variant record gets rep spec'd. =A0Let's sa= y I > >> have a sample of my record: > > >> type stuff(has_extra:boolean) is > >> record > >> =A0 =A0 foo: integer; > >> =A0 =A0 bar: integer; > >> =A0 =A0 case has_extra > >> =A0 =A0 =A0 =A0 when true =3D> > >> =A0 =A0 =A0 =A0 =A0 =A0 blah : float; > >> =A0 =A0 =A0 =A0 when false =3D> > >> =A0 =A0 =A0 =A0 =A0 =A0 null; > >> =A0 =A0 end case; > >> end record; > > >> for stuff use > >> record > >> =A0 =A0 foo at 0 range 0..31; > >> =A0 =A0 bar at 4 range 0..31; > >> end; > > >> type normal_stuff is new stuff(has_extra=3D>false); > >> type good_stuff is new stuff(has_extra=3D>true); > > >> for good_stuff use > >> record > >> =A0 =A0 blah at 12 range 0..31; > >> end record; > > >> for normal_stuff'size use 64; =A0-- 8 bytes > >> for good_stuff'size use 96; =A0 =A0-- 12 bytes > > >> First, does the discriminant take up any size in the record? > > > In "stuff", it almost certainly takes space. =A0If 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. =A0The 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. =A0If 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. =A0But eliminating the > > space for the discriminant is also possible. =A0(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. =A0That's no good. > > > Tagged records are a completely different animal, here. =A0First 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. =A0You can only use a rep clause to rearrange new fields > > in the type extension. =A0Second, you definitely can't move the tag to = a > > different place than in the parent type. =A0That 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. =A0This 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?) =A0So it is entirel= y > > 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? =A0Whatever 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. =A0That may mean not allocating size fo= r > > Blah since it will never exist in a Normal_Stuff anyway. =A0But when th= e > > 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. =A0If 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. =A0The language doesn't require tha= t > > a rep spec specify every field. =A0If 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). =A0So this is a legal rep > > spec. > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0-- 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