On 19 Mai, 01:25, Paul Pluzhnikov <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] writes: > > Could anyone tell me, why g++ cannot link in this case: > > Because it is invalid?
Some compilers really compile it. > > All other compilers I tried had no problems with this piece of code. > > They did? > > The only compiler I can link your code with is Sun CC (11 and 12) > and IBM xlC. > > All other compilers (VC6, 8, HP aCC), Intel icc -- fail with > unresolved `void doFunc<bool>()'. VC71, BCB 2006 It works. > > The member function "notUsed()" is declared "inline". However, the > > explicit template instantiation is implementing it. > > It isn't implementing anything. It is asking the compiler to provide > instantiations of all foo<bool>::* methods, which compilers other > than xlC and SunCC oblige to do, introducing the unresolved symbol. If g++ does not generate the code for "foo<bool>::notUsed()", how does g++ know that "doFunc<bool>()" is needed. > > The above construct helped me avoiding some terrible workarounds. What > > can I do to still use this way of implementation? > > You didn't tell what problem this helped you avoid, but if you > want to instantiate foo<bool>::notUsed(), then you must provide > doFunc<bool>() (in this, or some other compilation unit). NO, of course I don't want to instantiate foo<bool>::notUsed(). Instantiating "foo<bool>::notUsed()" would instantiate "doFunc<bool>()". Unfortunatelly, "doFunc<...>()" does not work for "bool". Therefore, using "notUsed()" for type "foo<bool>" should be prohibited. For "VC71" and "BCB 2006" the way shown in the example works: a) I do not use "foo<bool> obj; obj.notUsed();" => links well b) I use "foo<bool> obj; obj.notUsed();" => linker error (exactly what I want, because notUsed() is not available for foo<bool>) With g++ case (a) does not link :( I know, that I can spezialize template classes (e.g. for "foo<bool>"), but this would produce tons of nasty code. My example is a snapshot of more complex classes, of course. > > I had a look at some compiler switches like > > "-fno_implement_inlines"... but no, that doesn't work. > > Of course it doesn't work. How do you expect the compiler to come > up with body for doFunc<bool>() if you didn't supply one? You got me wrong. As I explained, I don't want to supply "doFunc<bool>()". > BTW, the only reason SunCC and xlC are able to link this is because > they ignore your explicit instantiation request (i.e. it's a bug > in the compiler -- they should have failed as well). > > Cheers, > -- > In order to understand recursion you must first understand recursion. > Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
