First Results

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!

The difficulty of templates

Now that I have had some time to get used to the needs and habbits of templates and STL containers I feel like not everything is as nice as it seems to be from the far distance....

Well, to start at the beginning, let me explain what I have done.

At first I decided to re-write the Sniffnose CORE SDK. And how? Yes with C++ templates. The reason for this decision is simple: It's more generic and I am forced to think about the code in a quite more detailed way. So I took some pieces of the existing code and modified it accordingly.

This made me aware of a problem I never got in touch with this intensively - exporting templates from dynamic libraries. Have you ever tried to do this? If not, don't just even try - it doesn't work. Well, it works, but only If you are willing to specialize the template and export this class - but why should I export a specialized template? It's not better than a "normal" class - DAMN!

And today I found a second thing. OK, this was more due to the fact that I haven't used templates intensively so far - especially the STL containers. Using const values in these containers is something which is not advisable, BUT there are compilers the are willing to accept these constructs - for instance VC.NET 2003. The funny thing about this is, that VC6 complains - btw: in a very cryptic way - about std::set :)

Hope you find this information useful.