Virtual Member templates

[Neelesh]

I wanted to know why member templates cannot be virtual -
is it because there is a conceptual impossibility in having them, or is
it because the current mechanism of implementaing virtual functons
would not work with that concept?

Assuming that a compiler doesnot support "export" keyword, I guess it
is necessary that all instantiations of the member template must get
the definition of the template (and hence the definition of the class
of which it is a member) at compile time. In such a case, it is
certainly not impossible for the linker to combine up the vtables to
generate a final entry (it is no different than combining individual
symbol tables, geneate a new one and resolve references.)

I might not be technically correct in what I have written above. So
please correct me if I am writing nonsense.

Thanks a lot.

[Alf P. Steinbach]

* Neelesh:

I wanted to know why member templates cannot be virtual -
is it because there is a conceptual impossibility in having them, or is
it because the current mechanism of implementaing virtual functons
would not work with that concept?

More that the C++ template mechanism is unconstrained, so that a
templated virtual function corresponds to an infinite number of
potential virtual functions, and you need whole program analysis to
determine which ones are actualized, and whole program analysis isn't
well supported by conventional C and C++ separate compilation.

In addition, outside the standard but well inside the realm of general
practical C++ usage, there is the problem of dynamic libraries.

With templated virtual functions a dynamic library would require dynamic
back-patching somewhere, to provide at run-time the equivalent of or a
substitute for the static whole program analysis.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ian]

Neelesh wrote:

I wanted to know why member templates cannot be virtual -
is it because there is a conceptual impossibility in having them, or is
it because the current mechanism of implementaing virtual functons
would not work with that concept?

Assuming that a compiler doesnot support "export" keyword, I guess it
is necessary that all instantiations of the member template must get
the definition of the template (and hence the definition of the class
of which it is a member) at compile time. In such a case, it is
certainly not impossible for the linker to combine up the vtables to
generate a final entry (it is no different than combining individual
symbol tables, geneate a new one and resolve references.)

It's not possible as all possible instantiations of the template would
have to be known when the class was compiled.

Ian