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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: kst@aonix.com (Keith Thompson) Subject: Re: OO, C++, and something much better! Date: 1997/01/19 Message-ID: #1/1 X-Deja-AN: 211226131 sender: news@thomsoft.com (USENET News Admin @flash) x-nntp-posting-host: pulsar references: <32DF458F.4D5C@concentric.net> organization: Aonix, San Diego, CA, USA newsgroups: comp.lang.ada originator: kst@pulsar Date: 1997-01-19T00:00:00+00:00 List-Id: (The References: header is probably incorrect. I saw Robert's response on the info-ada mailing list; it never appeared here in comp.lang.ada.) (Newsgroups trimmed to comp.lang.ada. Quoted text reformatted slightly.) Robert Dewar wrote: > Keith says > > On the other hand, for Ada 95, RM95-13.7.1(16) says that "Operations that > > do not make sense should raise Program_Error". The AARM (Annotated Ada > > Reference Manual) gives the examples of X < Y and conversions between > > Integer_Address and Address on a segmented architecture. (Note also that > > it's not necessary to use System.Storage_Elements; relational operators > > on type Address are provided in System.) > > Nope, you are reading too much into the RM here. Also reading the AARM > is always a risky business (remember it is just opinion, nothing more :-) Of course, but the AARM can be a perfectly good source of examples, which is all I used it for in this case. > Let's take the case of a segmented architecture. It is common for C > compilers in such environments (Large mode on the 8086) to limit objects > to 64K bytes and to compare ONLY the offset parts of the addresses > so that address comparison onlly works when it is defined to work, and > gives silent junk answers when used between different objects. Ok, no problem. > If we look at the corresponding Ada case, I cannot see any justification > whatsoever for not properly allowing conversoin of any possible segmented > address to an integer address. Such an operation makes perfect sense in > this environment and is therefore REQUIRED TO BE SUPPORTED! You are only > allowed to raise PE for things that do not make sense. Since this machine > has a well define notion of linear address, it is clear to me that (a) any > implementor on this environment would provide the obvious conversion and > (b) that if they did not, they could not seek refuge in the RM. Assuming that there's an integer type big enough to hold a full address (yes, this is probably a perfectly reasonable assumption). > Let's actually look at the AARM wording, it says, if we quote it in full, > rather than paraphrase as Keith did: > > 16.a Discussion: For example, on a segmented architecture, X < Y > might raise Program_Error if X and Y do not point at the same segment > (assuming segments are unordered). Similarly, on a segmented > architecture, the conversions between Integer_Address and Address > might not make sense for some values, and so might raise Program_ > Error. Note the phrase "assuming segments are unordered". On a segmented architecture of the kind you describe, segments are ordered (if I understand correctly). > Keith's point that there is a comparison operation on addresses directly > is true, but it is not a good idea to use these operations, since it is > indeed sensible to decide that certain comparisons are not meaningful > when performed directly on segmented addresses. That argument makes sense for C, but I don't think it does for Ada. If addresses can be converted to integers, and the resulting integers can be meaningfully compared, why on Earth would the relational operators in System not be implemented that way? How would you justify having System."<" compare only the offset parts of its operands? -- Keith Thompson (The_Other_Keith) kst@aonix.com <*> TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706 "SPOON!" -- The Tick