home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18543 < prev    next >
Encoding:
Text File  |  1992-12-30  |  2.2 KB  |  49 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!taumet!steve
  3. From: steve@taumet.com (Steve Clamage)
  4. Subject: Re: template disappointments ... (suggestions?)
  5. Message-ID: <1992Dec30.173230.22878@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <DSCHIEB.92Dec29133556@muse.cv.nrao.edu> <24508@alice.att.com> <1hqnd6INNe83@agate.berkeley.edu>
  8. Date: Wed, 30 Dec 1992 17:32:30 GMT
  9. Lines: 38
  10.  
  11. jbuck@foucault.berkeley.edu (Joe Buck) writes:
  12.  
  13. >In article <24508@alice.att.com> ark@alice.UUCP () writes:
  14. >>In article <DSCHIEB.92Dec29133556@muse.cv.nrao.edu> dschieb@muse.cv.nrao.edu (Darrell Schiebel) writes:
  15. >>>         list<vector<int>> list_vec_int;
  16. >>
  17. >>Huh?? This works fine -- just remember to put a space between the
  18. >>two > characters so the >> won't be taken for a shift-right symbol.
  19.  
  20. >This is such a common error (and is so ugly) that compiler writers
  21. >would be well advised to add productions to their grammar that catch
  22. >it, or magic that splits the >> token into two tokens in this case
  23. >if that fits in with the compiler's structure.
  24.  
  25. >Yes, I know that the rules of lexical analysis force the >> to be one
  26. >token, but list<vector<int>> is a perfectly natural way of writing
  27. >this thing, so perhaps it should be permitted even at the cost of
  28. >adding an ugly rule to the grammar.
  29.  
  30. It isn't quite as easy as it might appear.  We discussed the lexical
  31. and syntactic issues extensively in the C++ Committee.
  32.  
  33. In a template instantiation, the 'int' argument might be any expression,
  34. including one containing right shifts.  If you try to allow what appears
  35. to be a right shift to be two closing ">" instead, you wind up with
  36. nondeterministic lexing/parsing, ambiguous grammars, or context-sensitive
  37. grammars.  If you allow the above example to compile as the programmer
  38. intended, you will probably also allow examples to compile which
  39. really do contain syntax errors.  This can lead to bugs which are very
  40. hard to find.
  41.  
  42. There are already comparable lexical problems in C and C++, so we
  43. decided not to fix this one.  The above example is ill-formed code, and
  44. the compiler will complain.  This seems better than allowing ill-formed
  45. code which the compiler finds a way to accept.
  46. -- 
  47.  
  48. Steve Clamage, TauMetric Corp, steve@taumet.com
  49.