home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1931 < prev    next >
Encoding:
Text File  |  1992-12-29  |  2.9 KB  |  75 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!stanford.edu!lucid.com!lucid.com!jss
  3. From: jss@lucid.com (Jerry Schwarz)
  4. Subject: Re: Pointer comparisons
  5. Message-ID: <1992Dec29.042828.27808@lucid.com>
  6. Sender: usenet@lucid.com
  7. Reply-To: jss@lucid.com (Jerry Schwarz)
  8. Organization: Lucid, Inc.
  9. References: <1992Dec19.001851.22116@microsoft.com> <1992Dec23.182456.17185@lucid.com> <1992Dec24.200201.25709@microsoft.com> <1992Dec28.175218.15539@microsoft.com>
  10. Date: Tue, 29 Dec 92 04:28:28 GMT
  11. Lines: 62
  12.  
  13. jss:
  14. |> ||Does anything go for A's.  E.g.
  15. |> ||
  16. |> ||    void f() {
  17. |> ||        A a1, a2 ;  // can &a1==&a2 
  18. |> ||        ... ; 
  19. |> ||        }
  20. |> |
  21.  
  22. jimad:
  23. |> Let me restate the question as an answer.
  24. |> 
  25. |> Does the ARM anywhere say that two pointers of the same type to two different 
  26. |> objects of the same type not in the same array must compare not equal?  
  27. |> 
  28. |> If not then what does the ARM say of any such comparison?
  29.  
  30. As far as I can tell, except for the special cases enumerated in
  31. 5.9 and some hints about the behavior of new, the ARM 
  32. never requires two pointers to compare unequal.  I believe this is 
  33. an oversight and should be corrected in the standard when it emerges. 
  34. I believe the intention has always been that distinct objects have
  35. distinct addresses and I belive that the final standard should say so.
  36.  
  37. What should x3j16/wg21 do? One alternative would be to leave
  38. the words unchanged.  (I think this is Jim's position,
  39. but I'm not sure.)  This apparently allows &a1==&a2 in the above,
  40. and in other cases as well.  If the committee does this, it
  41. should do it explicitly after due consideration and not simply
  42. allow the status quo to remain by default.
  43.  
  44. Another possibility which has been proposed here recently (sorry
  45. I don't remember by whom)  is to add something like "two pointers to
  46. T (where T is an object type) compare equal if and only if they point
  47. to the same object".   This seems a useful rule to me.  Note that
  48. it makes no distinctions between "empty" and "non-empty"  classes.
  49. An alternative might be to apply this rule except for "empty"
  50. classes.  
  51.     
  52. So there really several related questions about this example.
  53.  
  54.     A: Does the ARM currently require a1!=a2?  Apparently 
  55.        not, but I may have overlooked something.
  56.  
  57.     B: What do existing compilers do.   How common is the
  58.        code that might be affected if the compiler was
  59.        changed to do something else.  How much existing
  60.            code currently assumes that a1!=a2.
  61.  
  62.     D: Should the standard when it emerges require a1!=a2.
  63.        I think yes, and am concerned with exactly how to
  64.        word this requirement.  There are many potential
  65.        examples and I would greatly prefer a general rule
  66.        to an enumeration of cases.
  67.  
  68. Knowing the answers to A and B for this and similar cases
  69. might influence my opinion  on C, but I am not prepared in advance
  70. to state a rule that would allow you to derive my opinion of C
  71. from the answers to A and B.
  72.  
  73.    -- Jerry Schwarz
  74.  
  75.