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!postnews.google.com!m3g2000pri.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Rep Specing Variant Records Date: Wed, 16 Sep 2009 08:03:37 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <2009091520225816807-rblove@airmailnet> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1253113418 7469 127.0.0.1 (16 Sep 2009 15:03:38 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 16 Sep 2009 15:03:38 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: m3g2000pri.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:8349 Date: 2009-09-16T08:03:37-07:00 List-Id: On Sep 15, 6:22=A0pm, R.B. Love wrote: > I want to understand how a variant record gets rep spec'd. =A0Let's say 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. 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. =A0That'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