home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11515 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  3.9 KB

  1. Path: sparky!uunet!cs.utexas.edu!torn!utgpu!attcan!ncrcan!scocan!simon
  2. From: simon@sco.COM (Simon Tooke)
  3. Newsgroups: comp.lang.c++
  4. Subject: re: >Committee Members -> What do you th
  5. Message-ID: <1992Jul24.132326.21294@sco.COM>
  6. Date: 24 Jul 92 13:23:26 GMT
  7. Sender: news@sco.COM (News administration)
  8. Organization: SCO Canada, Inc.
  9. Lines: 57
  10.  
  11. jimad@microsoft writes: 
  12. > In article <1992Jul15.144839.18494@sco.COM> paul@sco.COM (Paul Jackson) writes:
  13. > |By George, I think he's got it! A standard is NOT meant to be a perfect
  14. > |definition of a language that will stand unchanged for eternity, it is meant
  15. > |to be a checkpoint of "current" practice that allows programmers who care to
  16. > |write maximally portable code (note that these two features often conflict
  17. > |which is why standards have implementation defined and undefined behaviour).
  18. > |I put current in quotation marks since it is expected (and thought to be a
  19. > |good thing) that by the time a standard actually finishes wending its way
  20. > |through the system the current state of the art will already have passed it
  21. > |by.
  22. > Your definition of what a "standard" "is" flies in the face of the reality
  23. > of the ANSI-C++ committees actions.  In some cases, for example exceptions,
  24. > they have ignored existing implementations and chosen to require something
  25. > new different and not implemented in any compilers.  In other cases, such
  26. > as templates, they have decided to standardize on something that compilers
  27. > had not only not yet implemented, but which have not to this day been
  28. > even half-specified.  Thus compiler-implementors rush to support templates,
  29. > knowing not what they are suppose to implement, with the result that
  30. > each compiler claims they have templates, but it is virtually impossible
  31. > to write a meaningful template class that will work on various compilers.
  32. > In other cases the committee is soliciting "standard" class library
  33. > designs invented out of whole cloth -- classes for which there is no
  34. > implementation anywhere.  In other cases, such as name space, the committee
  35. > decided that existing implementations didn't have it right and they'd just
  36. > redesign the whole thing ....
  37.  
  38. By the time the committee wraps up, I expect most of the features being
  39. discussed today _will_ be common practice in the industry.  Or, are _all_
  40. compiler vendors going to hold off on all features above and beyond cfront
  41. 2.1 until they are fully worked through the committee?  I think Borland
  42. showed a bit of courage coming out with their version of templates when
  43. they did, and although they don't seem to work like the current working
  44. draft describes, I don't think porting will be a huge deal for most people.
  45.  
  46. > In a few years the ANSI-C++ committee will be [at best] just wrapping up
  47. > the proposed ANSI-C++ standard.  The standard will then go through several
  48. > years of public review before ratification.  The standard will then require
  49. > several more years before compiler vendors really bring their compilers into
  50. > conformance.  This is nothing new -- simply review the history of ANSI-C and
  51. > you can see how the ANSI-C++ process will progress!  Again, you are describing a
  52. > process VERY DIFFERENT from the actual actions of the ANSI-C++ committee, thus
  53. > your statement have no basis in reality as an argument against operator.()
  54.  
  55. It certainly did take time before truely ANSI-conformant compilers hit the
  56. streets, but many of the features that standard were available early.  I
  57. remember using function prototypes long before the standard came out.
  58. To have to wait until them for some of the more useful proposals (besides
  59. templates and exceptions, I like RTTI and ~const) seems a shame.
  60.  
  61. -simon tooke
  62.  
  63. ===============================================================================
  64. Simon Tooke                  SCO Canada, Inc.            Voice:  (416) 922-1937
  65. ....!scocan!simon             simon@sco.com                Fax:  (416) 922-2704
  66. 130 Bloor St. West. Suite 1001, Toronto, Ontario, Canada  M5S 1N5
  67.