home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1822 < prev    next >
Encoding:
Text File  |  1992-12-16  |  2.6 KB  |  54 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: Zero-length structures and pointer comparisons
  5. Message-ID: <9235215.11144@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <1992Dec8.173855.18153@meaddata.com> <1992Dec9.075125.22405@lth.se> <1992Dec12.154918.2220@ucc.su.OZ.AU> <1992Dec14.225659.24225@microsoft.com>
  9. Date: Thu, 17 Dec 1992 04:43:04 GMT
  10. Lines: 42
  11.  
  12. jimad@microsoft.com (Jim Adcock) writes:
  13.  
  14. >I think some flavor of "ptrcmp" makes sense on those implementations that
  15. >support casting pointers to integrals and back, and probably doesn't make
  16. >sense on those implementations that don't support the pointer/integral casts.
  17. >
  18. >In either case, I would ask what kind of sense it makes to write a "standard"
  19. >that *requires* a certain behavior of *some* implementation but doesn't
  20. >*require* that behavior of *all* implementations?  How do you justify such
  21. >a dichotomy?
  22.  
  23. ptrcmp() is intended to be universal, ie. required of *all* implementations.
  24.  
  25. >Such would be the proper designation, IMHO, for both the bidi pointer/integral
  26. >cast, and for the proposed "ptrcmp" macro.  Then, on Lisp machines, or 
  27. >C++ OODBMS's or whatever systens would find the total ordering 
  28. >practically unsupportable in their environment [...]
  29.  
  30. Why would ptrcmp() be practically unsupportable in these environments?
  31. OODBMS's maintain an object identity for each object, so it should be
  32. possible to base a total ordering on this object identity. I don't see
  33. the problems. What makes it difficult for Lisp machines? Are efficient
  34. BTrees and such-like genuinely impossible on such machines?
  35.  
  36. >In any case, "ptrcmp" would be a misnomer, because what is being compared
  37. >is *not* pointers, but rather the underlying *assumed* implementation of 
  38. >pointers using machine addresses.  The correct name might be something like 
  39. >"addrcmp" then, so as to not further confuse programmers on the difference
  40. >between language and implementation.
  41.  
  42. The function should be named after its interface, not its implementation.
  43. The function takes two (void *) _pointers_, and returns an integer which
  44. is meant to be a comparison of those pointers according to some total
  45. ordering.
  46. Whether it is implemented by comparing addresses or by sending mail to
  47. the Usenet Oracle and waiting for a reply is not relevant.
  48.  
  49. -- 
  50. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  51. This .signature virus is a self-referential statement that is true - but 
  52. you will only be able to consistently believe it if you copy it to your own
  53. .signature file!
  54.