home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1798 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  2.2 KB
  1. Path: sparky!uunet!mcsun!sunic!hagbard!loglule!jbn
  2. From: jbn@lulea.trab.se (Johan Bengtsson)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Zero-length structures and pointer comparisons
  5. Message-ID: <5385@holden.lulea.trab.se>
  6. Date: 15 Dec 92 19:06:22 GMT
  7. References: <1992Dec14.230730.24452@microsoft.com>
  8. Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
  9. Lines: 36
  10. X-Newsreader: TIN [version 1.1 + PL8]
  11.  
  12. Jim Adcock (jimad@microsoft.com) wrote:
  13. : In article <5366@miramon.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
  14. : |Other OODBMSs that use straight pointers to refer to persistent
  15. : |objects (e.g. ObjectStore,Texas) must provide a rather special
  16. : |ptrcmp(void*,void*), or disallow use of ptrcmp() for persistent
  17. : |objects (may be difficult to check).
  18.  
  19. : What if ptrcmp [addrcmp] were allowed to return 0 for those objects
  20. : and/or systems that don't define an ordering for those objects?
  21.  
  22. The problem is not to be able to order persistent objects, once
  23. you know that you have a void* refering to one.  Also, I wouldn't
  24. expect the comparison on persistent object IDs to be too slow to use,
  25. since we are talking about objects that anyway needs to be transferred
  26. to and from slow disks.
  27.  
  28. The real problem is distinguishing between void* to memory objects and
  29. void* to persistent objects.
  30.  
  31. : The implication would be that one routine could be written that uses
  32. : a fast ordering scheme on those OS's and/or objects that support the 
  33. : ordering, but a slower secondary scheme would have to be included for
  34. : those cases of objects or OS's where the order is undefined. 
  35. : The secondary scheme would only have to be implemented by those programmers
  36. : *really* interested in writing *really* portable code, since a defined
  37. : ordering out of ptrcmp would be a common extension.
  38.  
  39. I think systems that can't completely support ptrcmp() should simply
  40. refrain from defining it.  That will make the problem evident at an early
  41. stage (link time).
  42.  
  43. -- 
  44. --------------------------------------------------------------------------
  45. | Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
  46. | Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
  47. --------------------------------------------------------------------------
  48.