I'm implementing a templatized, virtual class in my scripting project. I read on www.cpluplus.com that if you create one of these, both the implementation and the declaration must be in the same file. After replacing my header with a .cpp file, I remembered how old that tutorial was. Is this rule still in effect?

Well, thanks(both). I'll just be good and put it all into a .h file.

Yeah the fabled tempate "export" feature has been dubbed a failed experiment in C++ standards/compilers. For production use you pretty much have to put templated and inlined code into header files.

Yes, I kind of understand why it doesn't work, I was just wondering if most compilers had implemented a way around it by now. Thanks for all the replies.

Edit: On second though, I really would like to know exactly why it doesn't work instead of the vague knowledge I have now. Anyone know?

but when the .cpp file is defined, isn't the header file included by it anyway? It seems like it would be just like one file to the compiler....

There are a number of problems that make export very difficult to implement. The first is that dependent names are unbound and looked up at the point of instantiation in the context of the instantiation. In other words, the full source of the template needs to be available at the point of instantiation. So seperate compilation of template code cannot eliminate the dependency of the source code on the template definition, it merely transforms the dependency from depending on the source code in form of a definitions in the translation unit to a form of some kind of object code.

The second problem is that separate compilation doesn't really buy you all that much, since the compiler still needs to load the template definition, so you most likely will not see decreased compilation time; indeed there may be an additional non-obvious dependencies introduced as the compiler attempts to find the template definition. In the worst case scenario, the compiler may have to examine the object code of all intermediate files and reject them all for not having the proper template source. This means that even if a vendor provides seperate compilation, the end user, seeing no advantage to separate compilation, may be less than satisified with the product. This is more of a business complication rather than a technical complication.

A third problem is that some symbols that may have previously had internal linkage or had storage optimized out must then have external linkage so that the template definitions can access the storage. This means that the context of template instantiation expands greatly, which in turn means that subtle cross-translation unit changes in meaning can occur in the generated template code. And then doing Koenig lookup in this kind of mixed context generates a number of difficulties in implementation.

There are probably other problems with implementing export, but those are more than enough by themselves.