NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/cplus/19964

Internet Message Format | 1993-01-28 | 6.4 KB

Path: sparky!uunet!tcsi.com!iat.holonet.net!news.cerf.net!usc!rpi!batcomputer!munnari.oz.au!metro!otc!swdev!grahamd
From: [e-mail] (Graham Dumpleton)
Newsgroups: comp.lang.c++
Subject: Re: Was: Template Use <sigh>
Message-ID: <[e-mail]>
Date: 27 Jan 93 00:06:54 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Technical Development Group, OTC Australia
Lines: 141


 > >->There are unresolved symbols, yet the instantiator doesn't do anything
 > >->about them.
 > >->
 > >->What am I doing wrong??? Any ideas?
 > >->
 > >->Guy.
 > >
 > >Put ALL of your template code in header (.h) files.  Do not put template
 > >code (member functions) in .c files.  In other words, get rid of
 > >loopuptable.c (or whatever you called it).
 > >
 > >This worked for me.
 >
 > It may work, but it is unnecessary with cfront 3.0.X.  We have several
 > very large systems under development here that utilize templates with
 > separate header and implementation files.
 >
 > The cfront auto instantiation system won't bother attempting template
 > instantiation if it cannot find its type map, which is the file
 > ptrepository/defmap by default.

As well as starting the template instatiation mechanism when there is a non
empty defmap file in the first or default repository directory, the AT&T
compiler will also start the template instantiation mechanism in a number
of other situations also. The list of cases that we have found, including
that that you mention, is:

  1) The default repository directory is being used or only one repository
  directory is explicitly defined on the command line, and there is a non
  empty defmap file in the repository directory.

  2) A single repository is being used and the directory doesn't contain a
  non empty defmap file but does contain a user provided nmap file.

  3) Multiple repository directories are defined explicitly on the command
  line and the first directory doesn't contain a non empty defmap file or
  user defined nmap files but a subsequent repository directory does.

I should point out that the HP C++ compiler version 3.0 (port of AT&T
3.0.1) doesn't start the instantiation mechanism in situations 2 and 3.
Someone in HP whom I had mail contact with does know about this now, however
whether they are changing their compiler to behave in the same way as the
AT&T compiler I do not know. The last I heard was that they were expecting
us to lodge a defect report, however since we don't actually have HP
machines we haven't had a reason to do that.

 > If one builds a library archive
 > containing unresolved template references in directory "A", then one
 > attempts to link against that archive in directory "B", template
 > instantiation will fail unless directory "B" happens to contain a type
 > map that allows cfront to locate all the types necessary to perform
 > the instantiation.

Due to situation 1 above.

 > If the user in directory "B" has the necessary
 > write permissions for the repository in directory "A", s/he can use
 > the -ptr option to the compiler to specify that repository instead of
 > the default, and the link should then work.  If repository "A" is not
 > writable, the user can specify a writable directory as the first
 > repository on the command line, followed by another -ptr specifying
 > "A" as a read-only repository:
 >
 >     CC ... -ptr my_ptrep -ptr A/ptrepository ...

Actually

     CC ... -ptrmy_ptrep -ptrA/ptrepository ...

I don't think it will accept a space after the -ptr.

Also this will not work with HP C++ 3.0, as it relies on situation 3 above.
What you can do is to create a dummy defmap file in the first repository
directory which contains something like

  @dec ____DUMMY____
  <____DUMMY____>

and it will then work.

 > All of this is well documented by the cfront release notes.

I would say that the exact situations in which the template instantiation
mechanism is started isn't actually well described. I could be wrong but
the only explicit mention I can find about this is:

  Selecting Readings page 8-14

    There is no easy way to tell whether an application uses templates, so
    the instantiation mechanism must cast its net widely. If the default
    repository exists and has a non-empty defmap file in it, the pre-linker is
    called.

Reading this in combination with the following which refers to the use of
multiple repositories:

  Selecting Readings page 7-10

    Type lookup in map files follows the algorithm in the section above on
    user overriding of name mapping files, except that the algorithm is
    applied in total to each repository left to right until the type is
    found.

you might conclude that if the first repository doesn't include a non empty
defamp file but a subsequent directory does then things may work, however
what I haven't found is any mention of the fact that instatiation will occur
even when you have no defmap files but do have nmap files.

 > We have found it useful to create archive libraries that utilize
 > templates in three steps:
 >
 >   1) create the archive library
 >   2) compile a dummy main program and link it against the archive

There isn't actually a need to supply a dummy main routine as the link will
simply fail with main undefined. It will still compile everything you need
though.

 >   3) redo the archive to include all of its original object files plus
 >      the object files created by the template instantiation system
 >
 > This approach prevents archive library clients from having to perform
 > template instantiation for that archive.  A similar approach is
 > mentioned in the cfront 3.0 release notes, I think.  Makes sense and
 > saves a lot of needless instantiation time.

We also make use of nmap files as local conventions mean that header files
don't necessarily have the same names as classes nor are they located in a
top level include directory but could be in a subdirectory. It is helpful
to have tools which can generate the nmap files and a make environment
which knows to go looking for them and stick them in the repository
directory.

Although not directly providing a solution to the original poster I hope the
extra information I have provided is of some assistance to someone. The area
of template instantiation is certainly tricky if you try to do things in
anything but the simplest way so any information can help.

--
Graham Dumpleton ([e-mail])