home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18551 < prev    next >
Encoding:
Text File  |  1992-12-30  |  2.4 KB  |  56 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!usc!howland.reston.ans.net!bogus.sura.net!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!cv3!dschieb
  3. From: dschieb@muse.cv.nrao.edu (Darrell Schiebel)
  4. Subject: Re: template disappointments ... (suggesti
  5. In-Reply-To: cflatter@nrao.edu's message of Wed, 30 Dec 1992 16: 51:54 GMT
  6. Message-ID: <DSCHIEB.92Dec30135756@muse.cv.nrao.edu>
  7. Sender: news@nrao.edu
  8. Organization: National Radio Astronomy Observatory
  9. References: <MCGRANT.92Dec29191250@gomez.stanford.edu> <1992Dec30.165154.25081@nrao.edu>
  10. Date: Wed, 30 Dec 1992 18:57:56 GMT
  11. Lines: 43
  12.  
  13. In article <1992Dec30.165154.25081@nrao.edu> cflatter@nrao.edu (Chris Flatters) writes:
  14. >
  15. >Newsgroups: comp.lang.c++
  16. >From: cflatter@nrao.edu (Chris Flatters)
  17. >Organization: NRAO
  18. >Lines: 47
  19. >
  20. >In article 92Dec29191250@gomez.stanford.edu, mcgrant@gomez.stanford.edu (Michael C. Grant) writes:
  21. >>
  22. >>In article <1992Dec29.204431.13413@nrao.edu>
  23. >>cflatter@nrao.edu (Chris Flatters) writes:
  24. >>   In article 92Dec29133556@muse.cv.nrao.edu,
  25. >>   dschieb@muse.cv.nrao.edu (Darrell Schiebel) writes:
  26. >>   >        class typeinfo {};
  27. >>   >        template<class t> class typeinfo : public typeinfo {};
  28. >>Yeah, that's a bummer. I see no reason why typeinfo and typeinfo<T>
  29. >>can't be distinguished by any reasonable compiler.
  30.     [explanation deleted]
  31. >In principle it is possible to envision a template name space that is separate
  32. >from the class name space but this would require the decision of whether an
  33. >identifier is a class name or a template name to be made with some awareness
  34. >of the context in which it appears.  This would rule out the use of LR(k)
  35.                                                                      ^^^^^
  36. >parsers (such as those generated by yacc) since syntactic elements are not
  37. >recognized until all of their components have been scanned.  This is a fairly
  38. >hefty price to pay.
  39.  
  40.     Although the Sun yacc man page says it "executes an LR(1) parsing 
  41.     algorithm". The hard copy docs state that it accepts LALR(1) grammars,
  42.     which is typical of most YACC implementations (A true LR parser with
  43.     an arbitrary number of lookahead tokens...I wish).
  44.  
  45.     Since one cannot have an argumentless template, I don't see any great
  46.     problem. Although, certainly it must be simpler to require that all
  47.     class and template name be distinct.
  48.  
  49. >because it is forbidden by the language definition
  50.  
  51.     And this is the point which makes this whole discussion moot.
  52.  
  53.  
  54.                         Darrell Schiebel
  55.  
  56.