home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18624 < prev    next >
Encoding:
Text File  |  1993-01-01  |  1.9 KB  |  42 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: <1993Jan1.170812.26511@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <24508@alice.att.com> <1hqnd6INNe83@agate.berkeley.edu> <1992Dec30.173230.22878@taumet.com> <1992Dec31.150138.22342@netcom.com>
  8. Date: Fri, 1 Jan 1993 17:08:12 GMT
  9. Lines: 31
  10.  
  11. erc@netcom.com (Eric Smith) writes:
  12.  
  13. >In article <1992Dec30.173230.22878@taumet.com> steve@taumet.com (Steve Clamage) writes:
  14. >>In a template instantiation, the 'int' argument might be any expression,
  15. >>including one containing right shifts.  If you try to allow what appears
  16. >>to be a right shift to be two closing ">" instead, you wind up with
  17. >>nondeterministic lexing/parsing, ambiguous grammars, or context-sensitive
  18.  
  19. >How is >> different from > in that respect?  a>b is a perfectly valid
  20. >int expression.
  21.  
  22. The '>' is always a '>' token.  The proposal was that sometimes '>>' is
  23. a '>>' token and sometimes it is two '>' tokens.  The compiler would have
  24. to decide which interpretation to use.  One interpretation might wind up
  25. being unparseable only after an arbitrary number of additional tokens.
  26.  
  27. Suppose there are several sets of '>>' in a template expression.  Each
  28. one is a branch point for additional possible parses.  The compiler has to
  29. verify that exactly one of a set of interpretations leads to a valid parse.
  30.  
  31. A whole new kind of parsing is therefore required just to allow
  32. programmers to omit a blank between consecutive closing template brackets.
  33.  
  34. It isn't impossible to have a language like this.  The question, as
  35. always, is whether the additional compiler complexity and other
  36. disadavantages are outweighed by the advantages.  The decision in C
  37. and C++ has always been to choose context-free lexical analysis and
  38. the "maximum munch" lexical rule.
  39. -- 
  40.  
  41. Steve Clamage, TauMetric Corp, steve@taumet.com
  42.