Actually, there's two related issues here, let's separate them. The
first is to
separate interface from implementation, the second
separate compilation.
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
.cpp extension. Now, the compiler needs to see the
template definition, so the implementation file must be
#included.
An easy way to get this is to put something like
#if defined(INCLUDE_TEMPLATE_DEFINITIONS)
#include "myclass_t.cpp"
#endif
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
it convenient.
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
instantiated. 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
export
keyword.
Second, separate compilation implies incremental compilation (by
compilation
unit). 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.