home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1846 < prev    next >
Encoding:
Text File  |  1992-12-21  |  2.7 KB  |  51 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Zero-length structures and pointer comparisons
  5. Message-ID: <1992Dec17.230520.13836@microsoft.com>
  6. Date: 17 Dec 92 23:05:20 GMT
  7. Organization: Microsoft Corporation
  8. References: <1992Dec12.154918.2220@ucc.su.OZ.AU> <1992Dec14.225659.24225@microsoft.com> <9235215.11144@mulga.cs.mu.OZ.AU>
  9. Lines: 40
  10.  
  11. In article <9235215.11144@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  12. |Why would ptrcmp() be practically unsupportable in these environments?
  13. |OODBMS's maintain an object identity for each object, so it should be
  14. |possible to base a total ordering on this object identity. I don't see
  15. |the problems. What makes it difficult for Lisp machines? Are efficient
  16. |BTrees and such-like genuinely impossible on such machines?
  17.  
  18. Of course BTrees and such-like are NOT impossible -- you just don't
  19. base them on pointers!  You base them on some other well defined total
  20. ordering of the objects, such as based on object surrogates.
  21.  
  22. Consider the case of OODBMSs where you use virtual memory schemes
  23. to trap on pointers to objects not in memory and then bring such
  24. objects into memory.  Such objects have unique [large] obids globally
  25. identifying them, and smaller pointers [addresses] to them in their
  26. current incarnations in memory.  Granted that an inverse mapping can
  27. give you the obid from the pointer, its just that such would typically
  28. be very slow compared to the address comparisons you expect.  Slower
  29. than using surrogates for example.  So why not use surrogates?
  30.  
  31. |The function should be named after its interface, not its implementation.
  32. |The function takes two (void *) _pointers_, and returns an integer which
  33. |is meant to be a comparison of those pointers according to some total
  34. |ordering.
  35. |Whether it is implemented by comparing addresses or by sending mail to
  36. |the Usenet Oracle and waiting for a reply is not relevant.
  37.  
  38. I strongly disagree.  Because systems that DO implement ptrcmp by
  39. sending mail to the Oracle are not going to be acceptable implementations
  40. *in practice* of what you require.  You insist for pedagogical reasons
  41. that *all* implementations support your hacks so that you can say your
  42. code is portable to *all* implementations even when in fact your code does
  43. not run acceptably on *all* machines.  Such code is NOT in fact portable.
  44. The portability of such code is pure fiction.  You ask that system
  45. implementors provide you with the implausible so that you can maintain
  46. your fiction.  I disagree.  Rather we should look at those capabilities
  47. that a *very* wide variaty of systems and implementations *can* reasonably
  48. *in reality* support, standardize on the *reality* not the fiction, 
  49. and leave the rest implementation defined.
  50.  
  51.