The question is pretty much fully embedded in the title.
views:
1013answers:
5Compile time polymorphism applies to functions and operator overloads.
Read this http://cpp-tutorial.cpp4u.com/OOP%5Fpolymorphism.html
Compile time polymorphism is a term that refers to C++ template programming. For example, at compile time you determine the actual type of a std::vector by what it contains:
std::vector <int> vi;
std::vector <std::string> vs;
I'm not sure why you think it it is limited to functions.
With compile time polymorphism one usually means the fact that you can have a several functions with the same name and the compiler will choose at compile time which one to used depending on the arguments:
void foo(int x);
void foo(float y);
//Somewhere else
int x = 3;
foo(x); //Will call first function
float y = 2;
foo(y); //Will call second function
The function foo
is said to be overloaded. Various types of template instantiation could also be called compile time polymorphism.
Way back when, "compile time polymorphism" meant function overloading. It applies only to functions because they're all you can overload.
In current C++, templates change that. Neil Butterworth has already given one example. Another uses template specialization. For example:
#include <iostream>
#include <string>
template <class T>
struct my_template {
T foo;
my_template() : foo(T()) {}
};
template <>
struct my_template<int> {
enum { foo = 42 };
};
int main() {
my_template<int> x;
my_template<long> y;
my_template<std::string> z;
std::cout << x.foo << "\n";
std::cout << y.foo << "\n";
std::cout << "\"" << z.foo << "\"";
return 0;
}
This should yield 42
, 0
, and ""
(an empty string) -- we're getting a struct that acts differently for each type.
Here we have "compile time polymorphism" of classes instead of functions. I suppose if you wanted to argue the point, you could claim that this is at least partially the result of the constructor (a function) in at least one case, but the specialized version of my_template
doesn't even have a constructor.
Edit: As to why this is polymorphism. I put "compile time polymorphism" in quotes for a reason -- it's somewhat different from normal polymorphism. Nonetheless, we're getting an effect similar to what we'd expect from overloading functions:
int value(int x) { return 0; }
long value(long x) { return 42; }
std::cout << value(1);
std::cout << value(1L);
Function overloading and specialization are giving similar effects. I agree that it's open to some question whether "polymorphism" applies to either, but I think it applies about equally well to one as the other.
The thing which only applies to functions is template parameter deduction. If I have a function template:
template <typename T>
void foo(T &t);
Then I can do int a = 0; foo(a);
, and this will be equivalent to int a = 0; foo<int>(a);
. The compiler works out that I mean foo<int>
. At least, it works out that it should use foo<int>
- if that's not what I meant then bad luck to me, and I could have written foo<unsigned int>(a);
or whatever.
However, if I have a class template:
template <typename T>
struct Foo {
T &t;
Foo(T &t) : t(t) {}
T &getT() { return t; }
};
Then I can't do int a = 0; Foo(a).getT();
. I have to specify Foo<int>(a)
. The compiler isn't allowed to work out that I mean Foo<int>
.
So you might say that class templates are "less polymorphic" than function templates. Polymorphism usually means that you don't have to write code to make the type of your object explicit. Function templates allow that (in this particular case), and class templates don't.
As for why this is the case - the standard says so, I don't know why. The usual suspects are (a) it's too difficult to implement, (b) it's not useful, in the opinion of the standard committee, or (c) it creates some contradiction or ambiguity somewhere else in the language.
But you can still do other kinds of polymorphism with classes:
template <typename T>
struct Foo {
T &t;
Foo(T &t): t(t) {}
void handleMany(int *ra, size_t s) {
for (size_t i = 0; i < s; ++i) {
t.handleOne(ra[i]);
}
}
};
This is usually also called compile-time polymorphism, because as far as the author of the template is concerned, t.handleOne
could be anything, and what it is will be resolved when necessary, "later" in the compilation when Foo is instantiated.