home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1844 < prev    next >
Encoding:
Text File  |  1992-12-21  |  3.0 KB  |  66 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.221057.10997@microsoft.com>
  6. Date: 17 Dec 92 22:10:57 GMT
  7. Organization: Microsoft Corporation
  8. References: <1992Dec12.154918.2220@ucc.su.OZ.AU> <1992Dec14.225659.24225@microsoft.com> <1992Dec16.150144.6004@ucc.su.OZ.AU>
  9. Lines: 55
  10.  
  11. In article <1992Dec16.150144.6004@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  12. |In article <1992Dec14.225659.24225@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
  13. |>I think some flavor of "ptrcmp" makes sense on those implementations that
  14. |>support casting pointers to integrals and back, and probably doesn't make
  15. |>sense on those implementations that don't support the pointer/integral casts.
  16. |
  17. |    Why not?
  18.  
  19. Because in the cases I can think of, if one fails to be reasonably implementable
  20. on a given system, the other also fails to be reasonably implementable, and
  21. since C already allows that systems NOT be required to support the
  22. pointer/integral cast.
  23.  
  24. |>In either case, I would ask what kind of sense it makes to write a "standard"
  25. |>that *requires* a certain behavior of *some* implementation but doesn't
  26. |>*require* that behavior of *all* implementations?  How do you justify such
  27. |>a dichotomy?
  28. |
  29. |    ptrcmp is standard, required function, it must yield a total
  30. |    order.
  31.  
  32. I was referring to the pointer/integral cast.  It is not required of
  33. all systems, only of some systems.  *Required* of *some* systems????
  34. This certainly contradicts my expectations of what a "standard" means!
  35.  
  36. |    In that case it is implementable on all systems
  37. |    where (opinion follows, please correct errors)
  38. |
  39. |    a) void* is big enough to hold all pointer types
  40. This assumption is almost univerally violated.
  41.  
  42. |    b) conversions always pad systematically
  43. |    c) bitwise comparison is done 
  44. |    d) the bits of a pointer cannot be magically changed by the system
  45. Violated  by real mode Windows, Violated by evacuating GC'ed machines.
  46. Violated by at least one GC'ed C++ implementation. Violated by
  47. at least some OODBMSs.
  48.  
  49. |    e) a pointer is implemented as an object in contiguous storage
  50. Probably violated by some OODBMSs.
  51.  
  52. |    Certainly, (e) might cause problems on the 80x86 where part of the
  53. |pointer is implicit and not physically stored. Does it *actually*
  54. |cause this problem?
  55.  
  56. No because implied segments can be made specific.  Segments can
  57. be moved on some systems however, implying an ordering that requires
  58. the segment part will not remain consistent.  Within a segment however,
  59. object orderings remain consistent.  Unless the PC is running a system
  60. with GC and ptr tracing, such that objects are moved to be compacted.
  61. Since such systems by a large margin have the best memory management
  62. that I've seen, I think it would be a big mistake to preclude them 
  63. for the kind of algorithm implemetation tricks you guys have been 
  64. talking about -- especially since surrogates or similar approaches
  65. can accomplish your goals about as well as the ptrcmp stuff.
  66.