home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1826 < prev    next >
Encoding:
Text File  |  1992-12-17  |  3.8 KB  |  92 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!nott!bnrgate!bcrka451!bcrki65!sjm
  3. From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
  4. Subject: Re: Pointer comparisons
  5. Message-ID: <1992Dec17.151642.9954@bcrka451.bnr.ca>
  6. Sender: 5E00 Corkstown News Server
  7. Organization: Bell-Northern Research Ltd., Ottawa, Canada
  8. References: <BzCG7K.2sG@frumious.uucp> <1992Dec16.202711.22367@bcrka451.bnr.ca> <BzDs2x.wA@frumious.uucp>
  9. Date: Thu, 17 Dec 1992 15:16:42 GMT
  10. Lines: 80
  11.  
  12. In article <BzDs2x.wA@frumious.uucp> uunet.ca!frumious!pat writes:
  13. >
  14. >   Two pointers to the same object compare equal.  If two pointers
  15.  
  16. ...but nowhere do I see a statement that (p == q) ==> p and q point
  17. to the same object, even if p and q are the same type.
  18.  
  19. Is it possible for two objects of the same type to be in different
  20. segments and compare equal?
  21.  
  22. >"Pointers ... may be compared".  Does this mean any pair of pointers
  23. >may be compared, or some pairs may be compared?  It certainly suggests
  24. >"any pair" to me, but some might interpret it as "some pairs".
  25.  
  26. I interpreted this as "a compiler is permitted to allow comparisons of
  27. pointers not specified in this document", but I use the word "may" to
  28. mean "is allowed to", not "might", and I don't know the meaning of
  29. "may" in legalese.  So yes, this wording is unclear to normal programmers.
  30.  
  31. >Let me try to be constructive for a change.  Would something
  32. >similar to the following be reasonable?  (It would clearly need
  33. >much more careful wording and attention to details.)
  34. >
  35. >1) Any two pointers to the same type may be compared, with any of
  36. >   the relational operators.
  37. >
  38. >2) In general, the results of the comparisons need not have anything
  39. >   to do with the objects to which the pointers point.  For example,
  40. >   it is possible that p and q point to the same object, but p != q.
  41. >   (But see below.)
  42.  
  43. Note that this provides your counterexample for    
  44.  
  45.    (p == q) <==> (ptrcmp(p,q) == 0)
  46.  
  47. Also, I would expect OODBMSs to use object ids to determine the ordering,
  48. so if p and q point to the same object but p and q are of different types,
  49. we might allow ptrcmp(p,q) == 0.
  50.  
  51. Or should equality mean "the same object and the same type"?  This
  52. might be unnatural if the OODBMS has a different concept of type than
  53. C++; for example, if the type of the OODBMS handle (smart pointer) is
  54. used to say "use this object as if it were an object of type T" instead
  55. of the typical C++ usage: "use the type T part of this object".  In the
  56. former case, the objects pointed to by the two pointers really are the same,
  57. even if one pointer has a restricted view of it.
  58.  
  59. >3) The relational operators define a total ordering on the set of
  60. >   pointers of each type.  (All the normal rules, including
  61. >   transitivity.)
  62.  
  63. Is this possible?  Mightn't some objects of one type be in one segment
  64. and some in another?  (Perhaps I should say "practical", not "possible").
  65.  
  66. >4) If two pointers p and q (of the same type) are obtained through
  67. >   sequences of "normal" operations, then
  68. >
  69. >      p == q   <==>   p and q point to the same object
  70.  
  71. I could not find this statement in the current wording.  Is there a 
  72. reason why the current wording is weaker than this?
  73.  
  74. What do you mean by "normal" operations?
  75. What are examples of "abnormal" operations?
  76.  
  77. >One might add a library function sameObject(p,q) which would
  78. >indicate whether p and q point to the same object, no matter
  79. >how p and q were obtained.
  80.  
  81. Is this necessary if we have ptrcmp?  If we like the name ptrcmp, shouldn't
  82. we like the name ptreq?  If we like sameObject, perhaps we should like
  83. cmpUsingObjectOrder(p,q)?  
  84.  
  85. Also, if p = (Base *)q, should sameObject(p,q) be 1?
  86.  
  87. Stuart
  88. --
  89. : Stuart MacMartin                                    email: sjm@bnr.ca      :
  90. : Bell-Northern Research                              phone: (613) 763-5625  :
  91. : PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
  92.