home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1845 < prev    next >
Encoding:
Text File  |  1992-12-21  |  3.9 KB  |  96 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Pointer comparisons
  5. Message-ID: <1992Dec17.224959.13288@microsoft.com>
  6. Date: 17 Dec 92 22:49:59 GMT
  7. Organization: Microsoft Corporation
  8. References: <BzCG7K.2sG@frumious.uucp> <1992Dec16.202711.22367@bcrka451.bnr.ca> <BzDs2x.wA@frumious.uucp>
  9. Lines: 85
  10.  
  11. In article <BzDs2x.wA@frumious.uucp> uunet.ca!frumious!pat writes:
  12. |"Pointers ... may be compared".  Does this mean any pair of pointers
  13. |may be compared, or some pairs may be compared?  It certainly suggests
  14. |"any pair" to me, but some might interpret it as "some pairs".
  15.  
  16. It means the compiler *will* accept code containing pointer comparisons
  17. as specified.
  18.  
  19. |"the result depends on the relative positions ... in the address
  20. |space."  What does this mean?  Must one convert the pointers into
  21. |actual addresses and return the result of comparing those addresses?
  22.  
  23. The meaning of "address space" is *as given in the specification.*
  24. IE the wording about the ordering of objects in an array, and members
  25. within a common declaration section.  The meaning of "address space" as
  26. defined by a conforming implementation need not be the same meaning of
  27. "address space" as implemented by the underlying CPU.  A simple example
  28. of this is the case of a C++ implementation targeting a P-code machine
  29. which in turn has a software-implemented virtual address scheme.  
  30. Yes people do write such implementation machines.  "Address
  31. Space" in this case refers to the *implementation* address space, not
  32. the *CPU* address space.  This in turn says its the *implementation* not
  33. the CPU that defines the meaning of these things.  The implementation simply
  34. has to implement its address space so that it meets the stated requirements
  35. of the standard.  Another [weaker] example of this is a 486 CPU which 
  36. can have a 48-bit virtual address space, but has *implementations* running
  37. assuming one or more cases [possibly within one program] of the following
  38. *implementation* models: 0:16, 2x0:16, 16:16, 0:32, 16:32, and 16+32.
  39.  
  40. If any implementation memory model meets the explicit requirements of
  41. the language specification, then such *is* the meaning of "address space".
  42.  
  43. |"If two pointers point to elements of the same array ...".
  44. |What if they point to members of elements?
  45.  
  46. Then you are allowed to *make* the comparison, but the *results* of the
  47. comparison are *implementation defined* since the results of such a
  48. comparison are not otherwise called out in the spec.
  49.  
  50. |   struct X { int a; int b; };
  51. |   X x[2];
  52. |
  53. |Must it be true that &x[0].a < &x[1].a?  
  54.  
  55. Nope.
  56.  
  57. What about &x[0].b < &x[1].a?
  58.  
  59. Nope.
  60.  
  61. The specification makes no such requirement, thus there is no such
  62. requirement.
  63.  
  64. |3) The relational operators define a total ordering on the set of
  65. |   pointers of each type.  (All the normal rules, including
  66. |   transitivity.)
  67.  
  68. Not reasonable for all the reasons already discussed.
  69.  
  70. |On systems where a pointer is composed of a segment identifier
  71. |and an offset, the compiler might arrange that the "normal"
  72. |operations would never change the segment identifier.
  73.  
  74. Such a compiler would not be useful on implementations requiring
  75. the segment identifier change.
  76.  
  77. |If we ignore the question of how much existing code this would
  78. |break, is this a reasonable suggestion?
  79.  
  80. No, because you would be ignoring the question of how much existing
  81. code this would break.  Including system implementations.
  82.  
  83. |And how much existing code would this break (that isn't already
  84. |broken)?  Note that it doesn't break any code that restricts
  85. |itself to "normal" operations.
  86.  
  87. "Normal" depends very much on what one is used to.  You expectations
  88. appear very "unnormal" to me. 
  89.  
  90. Code that depends on implementation details of address implementation
  91. has repeatedly proven to be very fragile in the past.  Let's not get
  92. sucked into depending on details of address implementaion again.  Let's
  93. give ourselves the freedom to run optimally on whatever machine appear
  94. today and in the future.
  95.  
  96.