I am using a library that consists almost entirely of templated classes and functions in header files, like this:
// foo.h
template
I have been working on the very same issue for quite a while now. In the solution you're proposing, you are defining your template classes twice. It will be ok if it defines the same stuff (in the same order), but you're bound to have problems sooner or later.
What i have come up with is to consider the problem the other way around. As long as you are not specializing your implementation, it works gracefully.
It uses two macros, which avois having to update template arguments in implementation file (be careful, though, if you want to add default template arguments to the class).
// foo.h
#define FOO_TEMPLATE template
#define FOO_CLASS Foo
FOO_TEMPLATE
class Foo {
Foo();
void computeXYZ();
};
// foo_impl.h
#include "foo.h"
FOO_TEMPLATE
FOO_CLASS::Foo(){}
FOO_TEMPLATE
void FOO_CLASS::computeXYZ() { /* heavy code */ }
By doing this, you essentially work the same way you do with non-template classes (you can do the same thing with template functions, of course).
EDIT : about the extern keyword in c++0x
I believe the extern keyword in c++0x will help, but it won't solve everything magically !
From this article,
Extern Templates
Every module that instantiates a template essentially creates a copy of it in the object code. Then, it's up to the linker to dispose of all of the redundant object code at the very last stage, thus slowing the critical edit-compile-link cycle that makes up a programmer's day (or sometimes daydreams). To short-circuit this object code garbage collection, a number of compiler vendors have already implemented an extern keyword that can go in front of templates. This is a case of standardization codifying existing industry practice (pun intended). In practice, this is implemented by sending a notice to the compiler basically to "not instantiate this here":
extern template class std::vector;