On Sep 10, 9:08 am, "Daniel T." <danie...@earthlink.net> wrote:
tony_in_da...@yahoo.co.uk wrote:
The point about polymorphism is that the implementation isn't
fixed by the function call itself.
A function pointer allows that, but is in no way polymorphic. It's
the ability to vary the types and get custom behaviour that defines
polymorphism.
How is the following not polymorphic?
struct Base {
void (*foo)(Base*);
};
struct Derived : Base {
};
void impa(Base* b) {
cout << "impa\n";
}
void impb(Base* b) {
cout << "impb\n";
}
void bar(Base* b) {
b->foo(b);
}
int main() {
Base b;
b.foo = &impa;
Derived d;
d.foo = &impb;
bar( &b );
bar( &d );
}
The above could be considered more polymorphic than C++s virtual table
system. After all, I can vary what function is called at runtime on a
per object basis.
In the code above you explicitly point two object's function pointers
at different implementations. Then you call them. There's nothing
switched on type, except in your head where you must believe that it
was due to the types that you picked those functions. I declare your
head polymorphic, but not your code. Nothing polymorphic has been
done for you. That Derived is derived is an irrelevance, except in as
much as you're illustrating the opposite of polymorphism: the ability
of one instantiation/compilation (of bar) to ignore the differences
between several types. That's more related to the old void* qsort
stuff mentioned earlier.
implement polymorphism. Maybe you can point to something that
To me, polymorphism is simply having the computer take care of your
'if's and 'switch'es implicitly. I can see making the case that taking
care of #if implicitly can be considered (compile time) polymorphism.
It's an interesting postulation, but I think there's a legitimate
distinction to be made...