home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / gnu / g / help / 1441 < prev    next >
Encoding:
Text File  |  1992-11-15  |  3.0 KB  |  64 lines
  1. Xref: sparky gnu.g++.help:1441 comp.lang.c++:16337
  2. Path: sparky!uunet!gumby!destroyer!cs.ubc.ca!pacific.cs.ubc.ca!not-for-mail
  3. From: upham@cs.ubc.ca (Derek Upham)
  4. Newsgroups: gnu.g++.help,comp.lang.c++
  5. Subject: Re: Where do templates go?
  6. Date: 15 Nov 1992 18:45:22 -0800
  7. Organization: Raven's Auto Body Repair Shop, Mega-Tokyo.
  8. Lines: 51
  9. Message-ID: <1e7202INN4rt@pacific.cs.ubc.ca>
  10. References: <DECHC00.92Nov13122503@tohi.DMI.USherb.Ca>     <1992Nov13.185422.28026@muddcs.claremont.edu> <DECHC00.92Nov15134442@tohi.DMI.USherb.Ca>
  11. NNTP-Posting-Host: pacific.cs.ubc.ca
  12.  
  13. dechc00@tohi.DMI.USherb.Ca (CHRISTIAN DECHAMPLAIN) writes:
  14.  
  15. >I understand the reasons why nobody wants to change the linkers, then how
  16. >about a pre-linker!
  17.  
  18. That's what I was thinking.  The C++ compiler already uses stabs (or
  19. whatever) to map object code back to the original source files; it
  20. should be possible to use the same features for generating templates.
  21. Have the compiler generate stabs information that points template
  22. symbols back to the original header files.  Just before the usual
  23. linking, a pre-linker sweeps through all the object files and looks
  24. for unresolved template symbols (the mangler should make template
  25. symbols obvious).  The pre-linker does consistency checks, then
  26. compiles the template source files for every needed case, without
  27. duplication.  After it's done, it strips the stabs info out of the
  28. original object files and calls the "regular" linker.  To save time,
  29. there might be an option to save the automatically generated ".o"
  30. files in the compilation directory.
  31.  
  32. There are a couple of simple ways of finding the definitions/source
  33. code with this method.
  34.  
  35.  * the library writer could just stick them into the header file (which
  36. would probably be compatible with the current G++ method---oh boy).
  37. The compiler would keep track of template definitions that it saw, but
  38. otherwise would just ignore them until pre-link time (at which point
  39. the header file would be interpreted as a regular source file).
  40.  
  41.  * the compiler could assume that if the header file was
  42. "/usr/include/foo.hh", then the corresponding source file would be
  43. named "/usr/include/foo.cc" (Dialect Alert!), stored in the same
  44. directory; the pre-linker would just look through the same set of
  45. #include directories as the pre-processor (which does mean the current
  46. directory as well).
  47.  
  48.  * To be really sure, the library writer could add a #pragma directive
  49. of some sort to the header file.  This would also be helpful as a
  50. supplement to the other two.
  51.  
  52. The first method has a slight edge in that it's a bit more
  53. idiot-proof.  It should also deal more gracefully with the case of a
  54. template function (as opposed to a template class with template
  55. members) that is defined and used throughout a single ".cc" file.
  56.  
  57. Derek
  58.  
  59. -- 
  60. Derek Lynn Upham                               University of British Columbia
  61. upham@cs.ubc.ca                                   Computer Science Department
  62. =============================================================================
  63. "Ha!  Your Leaping Tiger Kung Fu is no match for my Frightened Piglet Style!"
  64.