Re: Undefined reference to '...'
On Thu, 4 Sep 1997, Gonzalo A. Diethelm wrote:
> On Sep 3, 1997, at 13:47, Jason Gunthorpe wrote:
> > The trouble is that it doesn't recursively instantiate, ie if you use STL
> > and put the line
> > template class vector<int>;
> > In some .cc file to force instantiation then you will not get
> > instantiation of the helper functions the template uses, things like max,
> > min, etc. Furthermore the way gcc 2.7 has been choosing template instances
> > sometimes results in it generating a large number of pointless
> > instantiations when using stl. If you were to use explicit instantiation
> > with gcc 2.7 and STL you would end up with about 20 lines per stl class
> > you instantiate to catch all the functions and so on required.
> Well, I've been working on a big project (~200.000 lines C++ code) on
> Irix (Silicon Graphics), and it doesn't recursively instantiate
> templates either. While I agree it is cumbersome to manually
> instantiate EVERY template generated by your example, I think it is
Um, it would be interesting to see what ansi says, but if ansi's
recommendation is explicit non-recursive instantiation of each template
then they are truely mad. It is quite nice if you use templates sparingly
and not recursively, but..
The following generates 572 template instances when compiled with gcc
template class map<string,pkgElementId::Id *,less<string> >;
template class vector<string>;
template class SPtr<pkgPkgCtrlInfo>;
template class vector<pkgSPkgCtrlInfo>;
template class vector<GlobalError::Item>;
template class vector<pkgElmPkgList::Item>;
template class IPtr<Pointer>;
template class list<pkgElement *>;
template bool operator !=(pkgElement const &, pkgElementId const &);
template bool operator !=(IPtr<Pointer> const &, IPtr<Pointer> const &);
template bool operator !=(Pointer const &, Pointer const &);
template bool operator !=(pkgPkgList::iterator const &,pkgPkgList::iterator const &);
template bool operator !=(pkgElement const &,pkgElement const &);
The last couple are G++ bugs IMHO.
The sad part is that explicit non-recursive instantiation will never be
portable unless they standardize every class and function in all of stl,
no helper functions, even in private members.
On another project that did not use STL, but a custom array class I used
explicit instanciation, and it worked great!
> not such a big deal: you do it once (for each used template) and you
> are done. What's better, you know your code (executable or library)
> will only contain code that you are actually using, not a superset
> computed by the compiler to make sure things will work.
The linker should be smart enough to strip any un-used tempalte functions,
just as it would for any normal functions. By the same token the compiler
should only generate template functions if there is a chance they will be
I guess when I get egcs installed (waiting for libc6 xlib) I'll see if
they do recursive instantiation and bug them if they do not.
I think one of the better solutions might be the repo idea, but what I am
used to from the Win/Dos world is basically what Borland C does. Watcom,
VC, and High C all use COMDEFs to remove duplicated template functions.
High C used a prelink stage so their binaries were compatible with the
system linker that didn't support COMDEFs.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .