Is forbidding template virtual functions an unnecessary cautiousness? - c++

Question

After reading many posts about similar topics, and thinking about it for a while, still I do not understand why it is forbidden to implement template virtual functions.
The way I see it, this case has nothing to do with mixing static polymorphism with the dynamic one, but it is rather using template differentiation of the functions at the compile-time and then using dynamic polymorphism for each individual created function at the run-time.
Consider this piece of code:
class parrent{
public:
virtual float function(float value)const{
return value;
}
virtual double function(double value)const{
return value;
}
virtual long double function(long double value)const{
return value;
}
virtual ~parrent() = default;
};
class a_child:public parrent{
public:
float function(float value)const override{
return value + 1.5;
}
double function(double value)const override{
return value + 1.5;
}
long double function(long double value)const override{
return value + 1.5;
}
};
Obviously this code is OK and will achieve the expected result.
But using template to rewrite a similar code:
class parrent{
public:
template<typename t__>
virtual t__ function(t__ value)const{
return value;
}
virtual ~parrent() = default;
};
class a_child:public parrent{
public:
template<typename t__>
t__ function(t__ value)const override{
return value + 1.5;
}
};
Is not allowed.
I am not a compiler designer but from what I have read compilers will create a look up table from virtual functions and use them to launch the appropriate function at the run time, which is different from what they do in case of template functions. For any sets of template parameters given to use a template function at the compile time, compiler will create a unique function.
For this example compiler could detect template parameters in compile time simply by looking at how this virtual template function have been used throughout the entire program. Please consider the main function now:
int main() {
parrent* a;
parrent* b;
a = new parrent;
b = new a_child;
std::cout<< a->function(1.6f) << std::endl;
std::cout<< a->function(1.6) << std::endl;
std::cout<< a->function(1.6L) << std::endl;
std::cout<< b->function(1.6f) << std::endl;
std::cout<< b->function(1.6) << std::endl;
std::cout<< b->function(1.6L) << std::endl;
delete a;
delete b;
return 0;
}
Here Compiler will see that the function was used once for a float value, once for a double value and once for a long double value, so in any case it can easily create the right function with appropriate template parameters.
And in the end there will be 3 individual virtual functionS, not just one virtual function.
If we have a function which template parameters could not be deduced from the functions inputs like
template<typename t__>
virtual t__ function(int value){return value;}
Then users can just give the parameters themselves like:
object_pointer->function<double>(1234);
These practices are just what is already being used in case of any template functions, so why would it be different for virtual functions!
the only caveat to this practice that I can think of would be when the template virtual function get instantiated from a child object and never from the parent object or pointer.
Well even in that case same practice could be applied in order to create different virtual functions. Alternatively due to the lack of use of their virtuality they can become normal individual functions.
From the answer and comments it appears that there might be a serious problem with this approach which is obvious to every one else, so please be patient and help me understand it too.
I guess the mentioned problem in answers has something to do with compiler and/or linker not being able to know how many (and what type of) vtables it should produce for a class with regard to the rest of the codes or different translation units that it might face.
Well lets say it can produce an unfinished vtables list and extend it as it go along. The problem of ending up with two vtables or two different instances of a same class in the of case dynamic linking can already happen with instantiation of a template class with a virtual (non template)function.
So it seems that compilers already have a method to circumvent that problem!
First lets not forget that with regards to c, methods or class non static functions are nothing more than simple functions which require an object as one of their parameters, so lets not think of class as some intricate piece of code.
Second let's not get carried away by how compilers and linkers and what not works today. The language should be standard not the way compilers produce executable! Lets not forget that there are still many features in standard c++ 17 that even GCC does not cover yet!
Please explain to me in term of logic not the way compilers and/or linkers work what is the problem?

Answer 1

The way compilers implement polymorphic classes is as follows: the compiler looks at the class definition, determines how many vtable entries are needed, and statically assigns one entry in that vtable to each of the class's virtual methods. Wherever one of those virtual methods is called, the compiler generates code that retrieves the vptr from the class and looks up the entry at the statically assigned offset in order to determine the address that needs to be called.
We can now see how having a virtual template would cause issues. Suppose you had a class containing a virtual template. Now, after the end of the class definition, the compiler doesn't know how large to make the vtable. It has to wait until the end of the translation unit, to see the full list of the specializations of the template that are actually called (or to which a pointer-to-member is taken). If the class is only defined in this single translation unit, this problem could be solved by assigning vtable offsets to the template specializations in some increasing order in which they are encountered, then emitting the vtable at the end. However, if the class has external linkage, this breaks down, as when compiling different translation units, the compiler has no way of avoiding conflicts in the assignment of offsets to specializations of the virtual method template. Instead, the vtable offsets would have to be replaced with symbols that would be resolved by the linker once it has seen the list of referenced specializations from all translation units and merged them into a single list. It seems that if standard C++ required virtual templates to be supported, every implementation would have to require the linker to implement this functionality. I can guess that this will not be feasible any time soon.

Answer 2

I am not a compiler designer but I see a problem with what you are hoping to do.
When you have a virtual template member function, such as
template<typename t__>
virtual t__ function(t__ value)const{
return value;
}
there is no end to the types for which that is applicable. How does the compiler know whether to stop at int and double? There are unlimited number of types for which that function can be instantiated. Would you expect the compiler to generate vtable that takes into account all possible ways that function can be instantiated? That's infinite. It's not doable.