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-Thread: a07f3367d7,fc67383cc0841f25 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news1.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.posted.internetamerica!news.posted.internetamerica.POSTED!not-for-mail NNTP-Posting-Date: Wed, 16 Sep 2009 21:39:09 -0500 From: Robert Love Newsgroups: comp.lang.ada Date: Wed, 16 Sep 2009 21:39:09 -0500 Message-ID: <2009091621390916807-rblove@airmailnet> References: <2009091520225816807-rblove@airmailnet> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Rep Specing Variant Records User-Agent: Unison/1.8.1 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 76.31.96.179 X-Trace: sv3-U98z2CWn0frh/DBPkoxZrsBsVBAt/CIS16yvXvbXpkNgTKM1YBg+n2Ft2B5fEJOxWXc7Ct7FJoRjZzG!GAbzwWF2lcXZCrfE4fOlAmOmVF+/SCsOKcdX/4NhOHOpkorihV4fRvPuYNFkO9nP56VP+J6RiQrb!UA== X-Complaints-To: abuse@airmail.net X-DMCA-Complaints-To: abuse@airmail.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Xref: g2news2.google.com comp.lang.ada:8356 Date: 2009-09-16T21:39:09-05:00 List-Id: 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 said: > On Sep 15, 6:22�pm, R.B. Love 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