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-7-bit X-Google-Thread: 103376,a1ce307c10055549 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-12-19 12:46:23 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!newsfeed.telusplanet.net!xmission!news-out.spamkiller.net!propagator2-maxim!news-in.spamkiller.net!telocity-west!DIRECTV!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: calenday (was Re: IBM Acquires Rational Ada Date: Thu, 19 Dec 2002 14:46:44 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <5JfM9.395655$P31.145145@rwcrnsc53> X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:32095 Date: 2002-12-19T14:46:44-06:00 List-Id: Marin David Condic wrote in message ... >Tagged records probably present the worst problems if you try to throw >representation clauses on them. I've only tinkered with one compiler in this >regard, so I can't speak for all of them and I realize that there are >special problems in this respect. But if you're going to allow rep clauses >on tagged records, there ought to be some ability to actually make them >work. Two problems I had were that a) you have no mechanism to find the >position/size of the tag, so you have no mechanism to offset everything from >it and b) the compiler insisted that all extensions of the record start on a >longword boundary and there was no apparent way to tell it to start >elsewhere - even though it would have been an even byte or word boundary. It >seems to me that those are problems that *could* be addressed and maybe the >rep clause would be more useful. a) is not a problem in practice. We did this in Claw, and all compilers put the tag at offset 0. (A few can be told to put it elsewhere, but that wasn't generally available a few years ago when we did that.) The size is a problem in that it is implementation-defined. Ada.Tags.Tag'Size is the correct value, but it isn't static, so you can't use it in representation clauses. We ended up declaring a constant TAG_SIZE that we use in the rep. clauses (and compare to Ada.Tags/Tag'Size as a validity check). However, it is 4 (bytes) in all of the compilers that we tried, so it really wasn't necessary. b) is clearly compiler specific. I'd suggest trying to convince your compiler vendor to improve their compiler. Janus/Ada doesn't require any alignment for the extension part. And I don't recall having problems with this in Claw, although perhaps we were lucky. The biggest non-portability is in the ability (or lack thereof) to put extension components into "holes" in the parent. This is useful, but can be really hard to implement (it causes problems with the predefined "=" operation, and I believe that there are other problems that I don't remember at the moment). Randy Brukardt.