------- Additional Comments From jaco at kroon dot co dot za 2005-02-27 19:25 ------- Ok. The only reason I found this was cause I tried to compile quasar on my system. The code I supplied was the most reduced form I could create that duplicated the problem. As such I will attempt to make the smallest number of changes to the system (there is about 4 of these so I'll just go with the explicit instantiation for each as this is the way it currently works).
The "cover all cases" definition will need to be in the header file though right? Won't this produce duplicate symbols? Or will the linked automatically know to consolidate all these different symbols in the different object files into the same symbol in the produced executable? Yes, I was aware of the declaration vs definition problem (The book I learned C++ from explained this quite well), but I'm by no means a template guru, in fact, very far from (I use them in basic ways usually, even when using the STL). I was actually quite surprised that the compiler moaned in the first place, and was a bit skeptical about adding template <> cause that just felt/looked like a declaration and not a definition. Oh, and yes, the solution provided does work. Thank you very much for your help. One thing is sure though, I don't see the ambiguity between the statement with template<> ...::_types; and template <> ...::_types = ...; Both in my opinion is quite clearly a definition. We are defining that variable, for IntFactory, which as far as I can tell, is no longer really a template - why the template<> still? Someone explained to me that it is, actually, still a template, but doesn't take any more parameters (it's a specialisation of the template - this much makes sense). But as we are defining the _types static attribute, this is no longer a specialization - why is the template<> prefix still required? After all, it is simply a variable. I guess I just need to go and think about this for a bit to wrap my mind around it. Once again: Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11585
