After clicking 'next' a couple of times you come to:
7.4.4 The export keyword
At the time of writing, GCC does not support the new C++ export keyword (GCC 3.4.4).
This keyword was proposed as a way of separating the interface of templates from their implementation. However it adds its own complexity to the linking process, which can detract from any advantages in practice.
The export keyword is not widely used, and most other compilers do not support it either. The inclusion compilation model described earlier is recommended as the simplest and most portable way to use templates.
IOW, just put the code in the headers (or include the template's .c file in the template class's header file).
Templates are a bitch for the compiler to work out. Older systems I've used tried to be clever about it and would compiler everything, then try to link, an awk script would process the linker error messages, then generate some code, compile that and add it to the link. Given that linkers don't always exhaustively report all link errors, this was an iterative process that resulted in a 2 hour build rocketing up to over 24 hours in one pathological case. Rewriting templates as inline wrappers around C style code that required sizes as parameters everywhere moved the build time back to about 2 hours. IOW we did something like this:
class UnsafeArray
{
size_t _length;
size_t _capacity;
size_t _itemSize;
void* _data;
public:
UnsafeArray(size_t itemSize, size_t capacity) : _length(0), _capacity(capacity), _itemSize(itemsize), _data(malloc(_capacity*_itemSize)) {}
virtual ~UnsafeArray() { free(_data); }
};
template <class T>
class Array : private UnsafeArray
{
public:
Array(size_t capacity) : UnsafeArray(sizeof(T),capacity) {}
...
};
You get the idea - do the real work in real code and put syntactic sugar/type checking on it for the girly programmers (like me - pre coffee).