home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1779 < prev    next >
Encoding:
Text File  |  1992-12-14  |  2.2 KB  |  43 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: <1992Dec14.225659.24225@microsoft.com>
  6. Date: 14 Dec 92 22:56:59 GMT
  7. Organization: Microsoft Corporation
  8. References: <1992Dec8.173855.18153@meaddata.com> <1992Dec9.075125.22405@lth.se> <1992Dec12.154918.2220@ucc.su.OZ.AU>
  9. Lines: 32
  10.  
  11. In article <1992Dec12.154918.2220@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  12. |which cannot break existing implementations but provides a  total
  13. |order by way of a library function? If so, can we put this to
  14. |the library WG?
  15.  
  16. I think some flavor of "ptrcmp" makes sense on those implementations that
  17. support casting pointers to integrals and back, and probably doesn't make
  18. sense on those implementations that don't support the pointer/integral casts.
  19.  
  20. In either case, I would ask what kind of sense it makes to write a "standard"
  21. that *requires* a certain behavior of *some* implementation but doesn't
  22. *require* that behavior of *all* implementations?  How do you justify such
  23. a dichotomy?
  24.  
  25. On the contrary, I suggest that in a "standard" either something IS *required*
  26. of *all* implementations, or something IS NOT *required* of *all* 
  27. implementations.  If the committee cannot agree that something IS or IS NOT 
  28. *required* of all implementations, then what they should do instead is list 
  29. this something as a "commonly implemented extension to the language."
  30.  
  31. Such would be the proper designation, IMHO, for both the bidi pointer/integral
  32. cast, and for the proposed "ptrcmp" macro.  Then, on Lisp machines, or 
  33. C++ OODBMS's or whatever systens would find the total ordering 
  34. practically unsupportable in their environment, they simply would not implement
  35. the "common extension."  This would be a quality of implementation issue then,
  36. not an issue of conformance.
  37.  
  38. In any case, "ptrcmp" would be a misnomer, because what is being compared
  39. is *not* pointers, but rather the underlying *assumed* implementation of 
  40. pointers using machine addresses.  The correct name might be something like 
  41. "addrcmp" then, so as to not further confuse programmers on the difference
  42. between language and implementation.
  43.