Impact of templates on dlls/dsos?


You said that templates export poorly on Windows. What sort of things happen if you try to export templates? Are there any workarounds? To what extent does this impact linking with libpandaexpress.dll, libpanda.dll and so on?


This question has a complicated answer. I will try to answer it as succinctly as possible, but please bear with me. :slight_smile:

Windows requires all public symbols to be explicitly exported from a DLL via the __declspec(dllexport) syntax (and correspondingly dllimported when referenced in some other DLL). Surely there was a good reason for this early design decision, which I won’t attempt to touch. I guess it works pretty well on C libraries. But it doesn’t work so well on C++ libraries, particularly with template classes–the template itself, of course, doesn’t have a link-time presence, so it doesn’t make sense to dllexport a template. What you really mean to export is the template instantatiation. But template instantiations are implicit, according to the language, so where do you put the dllexport syntax?

Microsoft came up with a place to put the dllexport syntax, which is to explicitly put a line like this in the DLL that exports a particular template instance:

template class __declspec(dllexport) my_template_class<my_instance>;

And also put a line like this in a DLL that imports that template instance:

extern template class __declspec(dllimport) my_template_class<my_instance>;

These lines must be the first instantiation of the template instance, which means they must be seen by the compiler before any other reference to my_template_class<my_instance>.

Of course, this is a Microsoft extension to C++ syntax; the language itself does not require this sort of declaration (and non-Microsoft compilers won’t understand it).

The problem with this declaration is that it explicitly expands and exports all methods and components of the template class, whether they are actually used or not; and it requires that nested template classes be explicitly exported before their containing classes are exported.

That’s not too bad, but it turns out that the standard STL implementation of list, map, set, multiset, multimap–basically everything other than vector–use nested template classes that are mutually recursive. That is, the nested class includes references to the containing class, and vice-versa. This makes it impossible to export the nested classes first, since expanding them requires expanding the containing class–which has not been exported yet, violating the rule that the export syntax must appear before the first instance is encountered. Similarly, you can’t export the containing class first, which would expand the nested class before its export syntax. This means that none of the STL classes except for vector can be exported from a DLL.

But do you really need to export a template instance from a DLL? Isn’t each instance of a template technically a completely new copy of the class? If you don’t even try to export the class, you should end up with a new copy of the template code in each DLL, but since all of the copies are essentially the same, they should be compatible with each other. So what happens if you don’t try to export the class?

It turns out this works, mostly, but the standard implementation of STL relies on some static members of the template class, which the language specifies that the linker should resolve to the same pointer value by runtime. The Microsoft DLL linker doesn’t do this (because, without having explicitly exported the template classes, the linker sees them as unrelated classes). The net result is that any class that tries to expose iterators to its internal STL object, even via an inline method, will crash if those iterators are accessed by code in another DLL.

We spent a long time trying to figure out why our code, which worked fine on Unix, was crashing when we ported it to Windows. We finally tracked it down to this, and the only solution we could find–short of making everything non-inline and paying the corresponding run-time performance penalty–was to compile everything into one big DLL. Now, within the one DLL, all the iterators are valid and can be accessed by code in different modules.

This was back on VC6. Beginning with VC7.0, Microsoft started shipping with a third-party reimplementation of STL, that supposedly works around the DLL linker issue by not requiring static members to be unified. So presumably the issue is now a moot point on VC7.0 and above–you should be able to use STL iterators across DLL’s now, although you still pay the cost of code bloat–although we haven’t tested this.