home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1750 < prev    next >
Encoding:
Text File  |  1992-12-11  |  2.8 KB  |  54 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!cs.utexas.edu!torn!nott!bnrgate!bcrka451!bcrki65!sjm
  3. From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
  4. Subject: Re: Zero-length structures and pointer comparisons
  5. Message-ID: <1992Dec11.212831.19493@bcrka451.bnr.ca>
  6. Sender: 5E00 Corkstown News Server
  7. Organization: Bell-Northern Research Ltd., Ottawa, Canada
  8. References: <1992Dec10.051649.10282@jyu.fi> <5357@holden.lulea.trab.se>
  9. Date: Fri, 11 Dec 1992 21:28:31 GMT
  10. Lines: 42
  11.  
  12. In article <5357@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
  13. >Put differently: the database ID total order and the corresponding
  14. >transient pointer orders must be order-isomorphic (look it up, I did :-),
  15. >to ensure that the total pointer order for the addresses of
  16. >persistent objects mapped into transient memory is consistent between
  17. >different runs of the same program.
  18.  
  19. Aren't we talking about a total ordering that is consistent for the
  20. duration of the process?  The OODBMS objects can have an ordering that
  21. is persistent, but obviously the transient objects won't have a persistent
  22. ordering.  Do we care if the ordering of persistent objects is the same
  23. between different runs of the program?  Am I missing something?
  24.  
  25. And as I said in an earlier post (which you might not have read when you
  26. posted this), several OODBMSs allow multiple handles on the same object.
  27. Furthermore, Objectivity (for example) has a handle in which the actual
  28. address of the object in core is swizzled.  This swizzling is safe
  29. because it is private to the handle, and the user's program never sees
  30. the address of the actual object (if he is practicing safe programming).
  31. In fact, the object might not be in core even if the handle is valid, and
  32. the address in core may change unbeknownst to the user.  So the user
  33. does not have the address of the object, so he won't be comparing
  34. C++ pointers to these objects.  And in fact, comparing the address of
  35. the actual object will not give you the consistent ordering for the
  36. duration of the process unless you explicitly restrict the capabilities of
  37. the OODBMS.  Since this is all OODBMS specific, it is much better to
  38. let the OODBMS manage the ordering and forget about trying to get an
  39. ordering out of whatever handles it gives you.
  40.  
  41. All that long-winded explanation aside, I would like to be able to 
  42. define a total ordering on my objects - my persistent objects (stored in
  43. various OODBMSs) and my transient C++ objects - that is consistent for
  44. the lifetime of the objects and the duration of the process.  I don't 
  45. have any specific need for it at the moment, but I expect I would use this
  46. if I had it available.
  47.  
  48. Stuart
  49.  
  50. --
  51. : Stuart MacMartin                                    email: sjm@bnr.ca      :
  52. : Bell-Northern Research                              phone: (613) 763-5625  :
  53. : PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
  54.