Well, it's been a long time for me since I found the opportunity to write some lines. But that's now over. While more or less away I thought about some template related problems which I want to come up with a solution for. At least I think I found a way to deal with these problems a bit more elegently. In addition I took my time to start my first serious template coding affords.
So, here we go. The first tiny thing I already mentioned earlier is the problem of using templates in dynamically loadable entities such as DLLs or shared objects on unix platforms. My way of approaching this problem is quite simple since it doesn't require any special techniques. It's just a matter of how classes are designed - templated classes in special. Since the definition of a class, function or member function templates has to be known at the point of usage it is necessary to put the definition of those templates in the same header file as the declaration. Not doing so would result in a separation of the template declaration from the template definition which is no good idea since then the compiler is not able to generate code for the instantiated template after including the header. Only the template-id will be introduced, but later linker errors will occur.
At this point a must say that I act on the assumption that the inclusion model is used and not the separation model since an implementation of the export keyword is not spread very far. So I concentrate on this scenario.
Now, when designing a class I'd propose to separate that part of the class which is not templated and the other part which is dependent on the template parameters. The non-templated part is moved in an own class, say a core or impl class. This class is then made public (or if its functionality should be accessible only for the templated part then protected). This way we can provide an interface that can be exported from the library without problems.
The templated part then is derived from the core class, so that it doesn't need any member of it. Its implementation is done completely in one header (or in two with a class definition and an imline implementation of its methods.
The effect is, that when compiling the dynamically loadable library the functionality of the core class is exported (which is what we want). The template doesn't get any export/import declaration since it resides completely in headers. When the header is used in an application later the core will be imported (because all necessary parts of the library are imported by the application). And that's it. Easy!
