home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / std / cplus / 1515 < prev    next >
Encoding:
Text File  |  1992-11-08  |  3.3 KB  |  65 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!news.tek.com!uw-beaver!uw-coco!nwnexus!ole!ssc!eskimo!seanews!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Zero-length structures and pointer comparisons
  5. Message-ID: <1992Nov05.182917.14657@microsoft.com>
  6. Date: 05 Nov 92 18:29:17 GMT
  7. Organization: Microsoft Corporation
  8. References: <1992Oct28.184135.25475@ucc.su.OZ.AU> <1992Oct30.003946.10484@microsoft.com> <1992Nov4.071814.10880@ucc.su.OZ.AU>
  9. Lines: 54
  10.  
  11. In article <1992Nov4.071814.10880@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  12. |    Yes, I see. You are saying that by upgrading the requirements
  13. |to a total order existing confrming programs which are not strictly
  14. |conforming suddenly become non-conforming and are thus broken.
  15.  
  16. Yes, exactly.
  17.  
  18. |    Yes, I understand now I think. Leaving things 'implementation
  19. |defined' is then a complete barrier to ever upgrading those things
  20. |to be defined by the language without possibly breaking existing programs.
  21.  
  22. Yes, except the word is not "possibly" but rather "probably" because
  23. the vast majority of programs written are written in non-portable manner
  24. by programmers who neither understand nor care about portability.  Unfortunate,
  25. but true.
  26.  
  27. I'm not saying that you can't ever change an "implementation defined" to
  28. a "language defined" -- it just that you need to understand that such changes
  29. are *major* changes to the language -- not *minor* changes, and you better
  30. be darned sure that everyone buys into the associated cost.  Because a
  31. lot of programs are going to be suddenly busted, and a lot of compiler
  32. vendors are going to be solidly cursed by 100s or 1000s of customers for
  33. "gratuitously" changing their compilers in ways that suddenly "bust" programs
  34. that use to be "correct."  And such customers are right --  their programs
  35. were "correct" -- just not strictly conforming.
  36.  
  37. |    It might be the case if the class used < for the purpose
  38. |Andrew mentioned, and was otherwise a general purpose class.
  39. |This makes the class (rather than the program) the thing that we want
  40. |to make portable, i.e. the unit of reusability.
  41.  
  42. Agreed.  But note that requiring strict ordering would also make this
  43. class non-portable non-reusable on systems using C++ OODBMSs -- because
  44. you can't reasonably maintain a total ordering over a DB over a series of
  45. complete or partial passivations/activations.  Also merging/splitting DBs
  46. accross several computer systems becomes problematic if one assumes a total
  47. ordering.
  48.  
  49. |    I have not had access to these proceedings so know nothing
  50. |about previous battles. This sort of thing happens all the time here,
  51. |it would be good if there were better access to the proceedings,
  52. |as I'm sure you'll agree :-)
  53.  
  54. I agree, but the battles I was referring to happened even more moons ago
  55. in the ANSI-C committee.  The ANSI-C committee was pretty smart.  Things
  56. left implementation-defined were hard-won compromises between two or more
  57. groups that couldn't agree and so agreed to not agree.  Unfortunately, such
  58. has also got to be true of the ANSI/ISO-C++ effort.  You can only standardize
  59. what people widely agree to.  Everything else has to remain implementation
  60. defined.  If one faction or the other was truly "correct" in their strongly
  61. held position, then one can only assume their compilers will ultimately win
  62. in the marketplace -- and maybe could be agreed upon at the C+n standardization
  63. effort ;-)
  64.  
  65.