Actually, there's two related issues here, let's separate them. The
first is to separate interface from implementation
, the second
1. It is a good thing to separate interface from implementation
This can be achieved for templates by putting declarations in header
files and definitions in implementation files, for example with a
extension. Now, the compiler needs to see the
template definition, so the implementation file must be #include
An easy way to get this is to put something like
at the end of myclass_t.hpp.
*someone tell me how to revert to the above font, please*
This doesn't prevent the programmer from looking at the definition,
but at least she isn't forced to see it when she reads the interface.
2. Yes, separate compilation
requires the linker to be smart.
Again, there's two aspects here, being able to do it at all and making
First, as far as I can see, truly separate compilation (think of using
a library) requires the template definition to be available. This
effectively means that the source must be available to the linker,
which will pass it to the compiler when a template needs to be
d. Unless the source is delivered beside the library
file, it must be included inside of the library file. This appears to
be the straightforward way to implement the
Second, separate compilation implies incremental compilation (by compilation
). And this should apply to templates, too. If a
template has been instantiated for a particular template argument type
by one compilation unit, it should not be compiled again if a second
compilation unit instantiates it. Some if not many compiler/linker
duos use a template repository to achieve this. These linkers are
smart enough to call the compiler for help, should they realize that a
new template instance is needed.