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-20 13:49:03 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!sn-xit-01!sn-post-02!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: Fri, 20 Dec 2002 15:49:20 -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:32121 Date: 2002-12-20T15:49:20-06:00 List-Id: Marin David Condic wrote in message ... > 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. As noted elsewhere, Rational has at least one customer that wants to be able to place tags, and both Janus/Ada and Rational Apex support non-zero tag locations. Asking us to remove functionality (with the possibility for incompatibilities) is not likely to be looked on kindly. And, as also noted elsewhere, there are machines out there where a pointer (and thus a tag) is not 32-bits. How would you suggest we implement that rule on the U2200 with its 36-bit words (and pointers)?? >> 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..." :-) Well, it comes up when you're trying to minimize storage of the types, and the parent has unused bits. Consider: type Root_Type is tagged record Int : Some_Int_Subtype; Is_Valid : Boolean; end record; for Root_Type use record -- We assume the tag is at 0 and is 32 bits. A real rep. clause would use a constant instead -- of assuming the tag size is 4 below. Int at 4 range 0 .. 15; Is_Valid at 6 range 0 .. 0; end record; The bits 1 .. 7 in byte 6 are unused, as is byte 7. Now, look at the extension: type Day is (Sunday, Monday, ....); type Day_Type is new Root_Type with record The_Day : Day; end record; for Day_Type use record -- The_Day at 6 range 1 .. 4; -- No extra space needed. But fills a hole. The_Day at 7 range 0 .. 3; -- Extra byte needed. -- The_Day at 8 range 0 .. 3; -- Insisting on alignment makes it worse. Probably a 4 extra -- bytes when allocated. end record; And you waste even more space if some of the extension components need alignment. If there are going to be a lot of these (as there might if these are used in compiler expression trees, for example), the wasted space can turn into a lot of extra memory overhead (meaning longer compile times in this example). Randy Brukardt.