R
Robbie Hatley
Victor Bazarov said:Robbie said:[...]
I ran into a problem a few days ago when I added a couple of
template functions to one of my personal library headers.
My library, librh.a [...]
Linking is not defined by [the] C++ [standard].
Possibly true, but not very relevant. C++ translation units
must still be translated to machine language if one wishes
to actually EXECUTE one's program. And if there are more
than one translation unit (which is usually the case), then
the objects must be linked, regardless of whether or not the
standards committee chose to define the word "link" in some
special way.
Furthermore, the standard DOES indirectly "define" the concept
of "linking" by including the famous "one definition" rule. The
existance of a rule requires enforcement. Compilers are not
capable of enforcing this rule, because they operate on only one
translation unit at a time. Enforcing such a rule require a tool
which operates simultaneously on the tranlated versions of all
of the translation units of a project. Such a tool is called a
"linker".
Whatever you do to get where you are is implementation-defined.
Some things are implimentation defined; others are not.
The "one definition" rule is definitely not.
You are probably much better off asking this in the newsgroup
dedicated to your compiler/linker.
If my goal was to become an expert in certain fine points
of usage of one particular compiler and linker, and if
newsgroups existed for those tools, then that might be
the case.
But actually, my interest is more along the lines of how to
make my code more portable, rather than how to make it more
brittle.
Specifically, what I'd like to know is:
1. Is it normally necessary to declare a template function in a
header as being "inline"?
2. Is instantiating a non-inline template function in a library
object module likely to cause "redefinition" errors?
3. If a compiler first compiles the non-library object modules
for a program, instantiating a template in the processs,
then attempts to link to a pre-exising library object which
already contains an identical instantiation, could that cause
problems? Or should compilers and linkers be able to handle
that?
I find it hard to believe that no one here has ever had to deal
with such issues before, or that drastically different approaches
must be taken for each and every individual compiler and linker.
Surely there are better and worse ways of handling these issues?
--
Very curious (and persistant),
Robbie Hatley
Tustin, CA, USA
lone wolf intj at pac bell dot net
home dot pac bell dot net slant earnur slant