home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1820 < prev    next >
Encoding:
Text File  |  1992-12-16  |  1.3 KB  |  45 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!uunet.ca!frumious!pat
  3. From: pat@frumious.uucp (Patrick Smith)
  4. Subject: Re: Zero-length structures and pointer comparisons
  5. Message-ID: <BzDJHu.t2@frumious.uucp>
  6. Date: Wed, 16 Dec 1992 22:51:29 GMT
  7. Reply-To: uunet.ca!frumious!pat
  8. References: <1992Dec12.154918.2220@ucc.su.OZ.AU> <1992Dec14.225659.24225@microsoft.com> <1992Dec16.150144.6004@ucc.su.OZ.AU>
  9. Organization: None
  10. Lines: 33
  11.  
  12. maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  13. |    I'm not yet convinced it need bear ANY relation to
  14. |    ==, !=, < etc on pointers.
  15.  
  16. ["it" == ptrcmp]
  17.  
  18.  
  19. Surely one would want to insist on
  20.  
  21.    p == q   =>   ptrcmp(p,q) == 0
  22.  
  23. If this weren't true, one wouldn't be able to use ptrcmp as a basis
  24. for organizing an ordered binary tree for searching.  Are there any
  25. likely-to-be-common uses of ptrcmp which don't need this assumption?
  26.  
  27. Unfortunately, meeting this condition might be expensive on
  28. segmented architectures (according to the many other postings
  29. on this subject).
  30.  
  31.  
  32. The converse,
  33.  
  34.    ptrcmp(p,q) == 0   =>   p == q
  35.  
  36. seems not quite as essential, but still very useful.  Can anyone
  37. describe an otherwise reasonable implementation of ptrcmp which
  38. would _not_ meet this condition?  If not, what's the harm in
  39. asking for it?
  40.  
  41. -- 
  42. Patrick Smith
  43. uunet.ca!frumious!pat
  44. pat%frumious.uucp@uunet.ca
  45.