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
#include "myclass_t.cpp"
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.