home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 19786 < prev    next >
Encoding:
Text File  |  1993-01-23  |  3.3 KB  |  79 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!sdd.hp.com!apollo.hp.com!netnews
  3. From: vinoski@apollo.hp.com (Stephen Vinoski)
  4. Subject: Re: Was: Template Use <sigh>
  5. Sender: usenet@apollo.hp.com (Usenet News)
  6. Message-ID: <C1A4n9.1Iz@apollo.hp.com>
  7. Date: Fri, 22 Jan 1993 23:45:09 GMT
  8. References: <1jp50dINNk34@rs6000.bham.ac.uk> <81348@hydra.gatech.EDU>
  9. Nntp-Posting-Host: srv.ch.apollo.hp.com
  10. Organization: Hewlett-Packard Corporation, Chelmsford, MA
  11. Lines: 66
  12.  
  13. In article <81348@hydra.gatech.EDU> mhopper@cerl.gatech.edu (Michael A. Hopper) writes:
  14. >In article <1jp50dINNk34@rs6000.bham.ac.uk> pickerig@eee.bham.ac.uk (Guy Pickering) writes:
  15. >->Anyway, my problem in more detail is this: I have three directories
  16. >->which contain the following:
  17. >->
  18. >->  1/ The .C and .H files defining the template class LookupTable.
  19. >->  2/ The .C and .H files of an algorithm which uses LookupTable<unsigned
  20. >->     char>
  21. >->  3/ A main.C which binds the whole lot together, but does not itself
  22. >->     use LookupTable<unsigned char>
  23. >->
  24. >->The problem is that at link time, no template instantiation takes
  25. >->place and then the real linker complains about all my member functions
  26. >->of LookupTable<unsigned char> being unresolved.
  27. >->
  28. >->There are unresolved symbols, yet the instantiator doesn't do anything
  29. >->about them.
  30. >->
  31. >->What am I doing wrong??? Any ideas?
  32. >->
  33. >->Guy. 
  34. >
  35. >Put ALL of your template code in header (.h) files.  Do not put template
  36. >code (member functions) in .c files.  In other words, get rid of loopuptable.c
  37. >(or whatever you called it).
  38. >
  39. >This worked for me.
  40.  
  41. It may work, but it is unnecessary with cfront 3.0.X.  We have several
  42. very large systems under development here that utilize templates with
  43. separate header and implementation files.
  44.  
  45. The cfront auto instantiation system won't bother attempting template
  46. instantiation if it cannot find its type map, which is the file
  47. ptrepository/defmap by default.  If one builds a library archive
  48. containing unresolved template references in directory "A", then one
  49. attempts to link against that archive in directory "B", template
  50. instantiation will fail unless directory "B" happens to contain a type
  51. map that allows cfront to locate all the types necessary to perform
  52. the instantiation.  If the user in directory "B" has the necessary
  53. write permissions for the repository in directory "A", s/he can use
  54. the -ptr option to the compiler to specify that repository instead of
  55. the default, and the link should then work.  If repository "A" is not
  56. writable, the user can specify a writable directory as the first
  57. repository on the command line, followed by another -ptr specifying
  58. "A" as a read-only repository:
  59.  
  60.     CC ... -ptr my_ptrep -ptr A/ptrepository ...
  61.  
  62. All of this is well documented by the cfront release notes.
  63.  
  64. We have found it useful to create archive libraries that utilize
  65. templates in three steps:
  66.  
  67.   1) create the archive library
  68.   2) compile a dummy main program and link it against the archive
  69.   3) redo the archive to include all of its original object files plus
  70.      the object files created by the template instantiation system
  71.  
  72. This approach prevents archive library clients from having to perform
  73. template instantiation for that archive.  A similar approach is
  74. mentioned in the cfront 3.0 release notes, I think.  Makes sense and
  75. saves a lot of needless instantiation time.
  76.  
  77. -steve
  78.  
  79.