Re: Explicite Template Instantiation and Inline

[tthunder]

On 19 Mai, 01:25, Paul Pluzhnikov <ppluzhnikov-...@charter.net> wrote:
> tthun...@gmx.de 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.