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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no 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-20 05:16:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!arclight.uoregon.edu!wn14feed!wn12feed!worldnet.att.net!207.217.77.102!newsfeed2.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: calenday (was Re: IBM Acquires Rational Ada Date: Fri, 20 Dec 2002 08:15:22 -0500 Organization: MindSpring Enterprises Message-ID: References: <5JfM9.395655$P31.145145@rwcrnsc53> NNTP-Posting-Host: d1.56.b7.ce X-Server-Date: 20 Dec 2002 13:20:51 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:32106 Date: 2002-12-20T13:20:51+00:00 List-Id: Randy Brukardt wrote in message news:v04c0ul05vht40@corp.supernews.com... > > > 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. > I'd suspect that declaring in the standard that all tags shall start at offset 0 and extend for 32 bits would not cause anyone any rework. I doubt it would come up often that the offset needed to be anything other than zero - I can't think of why I'd want it to or why I couldn't make things work somehow if it were always zero. Having a predefined constant for size and a mandated (dare I use that word?) starting point at the beginning of the record ought to be good enough. > 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. > Well, someone must have thought it was more important to longword-align things than to give the programmer what he asked for. :-) The important part is that if you're going to have a rep-clause, it needs to give the programmer control over the representation - even if it introduces inefficiencies. > 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). > That starts sounding a bit extreme. The overwhelming bulk of the time, I'd be trying to use rep-clauses because things are packed tightly together - not overlapping things. Most typically for tagged records, you'd have a class called "Message" that included message header info then followed by a variety of message formats - very naturally expressed in OO Design. But if you can't control representation, you can't make it work with what happens on the wire. Short of the base class ending in the middle of a byte (never seen that) and wanting the derived class to pick up in the middle of that byte, I can't think of a case where I'd want derived class parts put into holes in the base class. Maybe it happens, but I think you could probably put on my tombstone "He never packed derived class data into holes in the base class..." :-) MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "I'd trade it all for just a little more" -- Charles Montgomery Burns, [4F10] ======================================================================