Template instantiation in libraries

[Garrett Kajmowicz]

In an attempt to cut down on the verbiage, I have been vague to the point
that what I have said has been useless.  Here goes yet another attempt.

I am implementing the standard C++ library with the target being embedded
systems.  Toward that end I am focusing on small code, lower memory
usage, etc.  The standard C++ library is mostly templates.  In order to
cut down on the amount of code being put into each and every executable
being compiled, my intention was to instantiate many of the common
versions of these templates with the intention of having the code be used
out of the library and not be stored in the application.  Ex, I'm
expanding much of the code for std::basic_string<char> (also known as
std::string) because it is commonly used.

Unfortunately, even when the required code is placed in the library, the
compiler/linker defaults to creating an instantiated copy of the template
code in the executable as a weak symbol.

I can understand the idea of instantiating the template in the code (so
that it is there if needed) and discarding duplicate copies (which is what
happens).  However, I am unable to figure out how to get the compiler or
(ideally) my library code to specify that in the binary that if a version
of the function is available in the library it is being linked against
that it should not be kept as a weak symbol.

Is there any easy way to do this after-the-fact with binutils?

I have found a partial solution.  For cases where I want to provide
certain versions of a template, I define a specialized version of the
template in the header file, but put the definition in a .cpp file and
compile it into the library.  This works and prevents instantiation when
compiling.  However, it results in my having to have duplicate copies of
the code kicking around, which is bad engineering and bad for
maintenance, etc.

My solution to that problem was to create a dummy template class/function
and put the real code in there.  Then the public functions call the
private functions which actually do the work. This works but involves some
workarounds and kind of kludgey.

Hence my reason for trying to find ways to get the compiler/linker to use
the library version of a symbol if available and thus discard the internal
versions.

Thank you for your patience.
-       Garrett Kajmowicz