# Virtual Methods vs. Polymorphism

## Recommended Posts

Okay, I think I am grasping oop concepts from this article at developer.com :http://www.developer.com/tech/article.php/3488176 But I was wondering what virtual methods were and what they are used for :http://newdata.box.sk/bx/c/htm/ch12.htm [Edited by - Tradone on March 14, 2006 5:37:57 PM]

##### Share on other sites
z80    134
They are used to implement polymorphism.

##### Share on other sites
Basically what you want to do when using virtual functions is call a method of an object without concern for the object type and the proper implementation of that method, as long as that method exists. This is what polymorphism employs in OOP : a function with multiple implementations, depending on which object it is applied to. You need not know how an object does a certain modification, as long as it does it and it has the same name (so you cand access it through a pointer).
Hope this makes sense.

##### Share on other sites
I understand the basics of polymorphism, but having trouble distinguishing between polymorphism and virtual methods.

are they essentially the same thing?

##### Share on other sites
Conner McCloud    1135
Quote:
 Original post by TradoneI understand the basics of polymorphism, but having trouble distinguishing between polymorphism and virtual methods.are they essentially the same thing?

Virtual methods enable polymorphism. Polymorphism is treating several different types as the same, but retaining their specific functionality. Virtual methods is the way you do that.

Objects vs object oriented programming. Stock cars vs NASCAR. And so forth.

CM

##### Share on other sites
Way Walker    745
Quote:
 Original post by TradoneI understand the basics of polymorphism, but having trouble distinguishing between polymorphism and virtual methods.are they essentially the same thing?

Think of it this way. The virtual keyword is one way C++ implements polymorphism. Templates are another way that C++ implements polymorphism. Smalltalk implements polymorphism using messages. Haskell implements polymorphism through type inference.

For what it's worth:
#include <iostream>using namespace std;namespace WithoutVirtual {    class A            { public: void foo() { cout << "class A\n"; } };    class B : public A { public: void foo() { cout << "class B\n"; } };}namespace WithVirtual {    class A            { public: virtual void foo() { cout << "class A\n"; } };    class B : public A { public:         void foo() { cout << "class B\n"; } };}int main() {    WithoutVirtual::A  a;    WithoutVirtual::B  b;    WithoutVirtual::A *pa;    WithVirtual::A  va;    WithVirtual::B  vb;    WithVirtual::A *pva;    cout << "Without virtual:\n";    pa = &a;    cout << "Called foo() on object of class A and get foo() on ";    pa->foo();    pa = &b;    cout << "Called foo() on object of class B but get foo() on ";    pa->foo();    cout << "With virtual:\n";    pva = &va;    cout << "Called foo() on object of class A and get foo() on ";    pva->foo();    pva = &vb;    cout << "Called foo() on object of class B and get foo() on ";    pva->foo();}

This prints out:
Without virtual:Called foo() on object of class A and get foo() on class ACalled foo() on object of class B but get foo() on class AWith virtual:Called foo() on object of class A and get foo() on class ACalled foo() on object of class B and get foo() on class B

Without virtual, B can't really take on the form of A. Virtual allows B to take on the form of A (i.e. B has more than one form or is polymorphic).

##### Share on other sites
Just to clarify something: polymorphism is a mecanism that binds a function to more than one definition. Virtual methods implements a special kind of polymorphism (inheritance (or subtyping) polymorphism). If you define 2 functions that have the same name and a different list of parameters, you are using another kind of polymorphism called "ad hoc polymorphism".

Regards,

##### Share on other sites
Shamino    100
Question, is it "fake" polymorphism when you program more than one object to have the same function name (which does basically the same thing), but with no inheritence involved?

Like say, a renderable object with a render function..

We have milkshape models, they have a draw function
we have user defined geometry, they have draw functions..

etc etc..

##### Share on other sites
Quote:
 Original post by ShaminoQuestion, is it "fake" polymorphism when you program more than one object to have the same function name (which does basically the same thing), but with no inheritence involved?

Polymorphism is a very general term in computer science. In short, yes, having multiple types with member functions of the same name can be considered polymorphism depending on how they are used. In addition to that, simple overloaded functions can be considered polymorphism, and even common built-in language operations such as +, -, etc. can be considered a form of polymorphism if they can work with different built-in types such as int and float in c++.

The difference is that, in a statically-typed language, those are all forms of compile-time polymorphism whereas virtuality is usually a runtime language facility. That means that you can use virtuality to give to polymorphic behaviour when the choice is made at runtime, whereas with the other forms of polymorphism just described must determine the implementation to be used at compile-time.

##### Share on other sites
Guest Anonymous Poster
Quote:
 Original post by ShaminoQuestion, is it "fake" polymorphism when you program more than one object to have the same function name (which does basically the same thing), but with no inheritence involved?

If by "fake" you mean "parametric", then yes.

##### Share on other sites
Shamino    100
Hmmm...

It seems, in most cases, without parametric polymorphism, you need some type of type switching to figure out what kind of function you would need to call..

Say I have a scene graph, and no matter what, a geometry node in a scene graph calls the draw function on a pointer it is given..

geometry->draw();

Now, if geometry doesn't have a draw method, the system breaks, but you just make sure that everything you can draw has a draw method that allows the object to be drawn on the scene..

Is this parametric polymorphism? If so, it seems to work well.

##### Share on other sites
Quote:
 Original post by ShaminoHmmm...It seems, in most cases, without parametric polymorphism, you need some type of type switching to figure out what kind of function you would need to call..Say I have a scene graph, and no matter what, a geometry node in a scene graph calls the draw function on a pointer it is given..geometry->draw();Now, if geometry doesn't have a draw method, the system breaks, but you just make sure that everything you can draw has a draw method that allows the object to be drawn on the scene..Is this parametric polymorphism? If so, it seems to work well.

Most of the time you'll use inheritance polymorphism here - your node type will inherit the SceneNode class and draw() will be a virtual method in SceneNode.

So no, it's not parametric polymorphism :)

Regards,

##### Share on other sites
snk_kid    1312
Quote:
 Original post by Way WalkerThe virtual keyword is one way C++ implements polymorphism.

sub-type polymorphism.

Quote:
 Original post by Way WalkerTemplates are another way that C++ implements polymorphism.

There original intent was for parametric polymorphism but there not true parametric polymorphism, there abit of a beast (not in the good sense) so i'd say it's more of mismash of ad-hoc & parametric polymorphism.

Quote:
 Original post by Way Walker Smalltalk implements polymorphism using messages.

Again it's sub-type polymorphism as is the case when OO speaks of polymorphism.

Quote:
 Original post by Way Walker Haskell implements polymorphism through type inference.

Well not exactly it's part of the process though, anyways haskell has parametric polymorphism and ad-hoc polymorphism (that is less ad-hoc) via type classes.

Quote:
Original post by Anonymous Poster
Quote:
 Original post by ShaminoQuestion, is it "fake" polymorphism when you program more than one object to have the same function name (which does basically the same thing), but with no inheritence involved?

If by "fake" you mean "parametric", then yes.

@Shamino: no it's not right to call it "fake".

Quote:
 Original post by ShaminoHmmm...It seems, in most cases, without parametric polymorphism, you need some type of type switching to figure out what kind of function you would need to call..Say I have a scene graph, and no matter what, a geometry node in a scene graph calls the draw function on a pointer it is given..geometry->draw();Now, if geometry doesn't have a draw method, the system breaks, but you just make sure that everything you can draw has a draw method that allows the object to be drawn on the scene..Is this parametric polymorphism? If so, it seems to work well.

Well i have no idea what you're trying to say but that doesn't sound like parametric polymorphism, either you're talking about sub-type polymorphism or ad-hoc polymorphism AKA overloading. Also note overriding is a special case of overloading, the only difference is resolution happens at runtime instead of at compile-time.

[Edited by - snk_kid on March 15, 2006 1:33:15 PM]

##### Share on other sites
Way Walker    745
Quote:
 Original post by Emmanuel DelogetMost of the time you'll use inheritance polymorphism here - your node type will inherit the SceneNode class and draw() will be a virtual method in SceneNode. So no, it's not parametric polymorphism :)

The article you linked to points out that "sub-type polymorphism" (I assume that's what you're refering to as "inheritance polymorphism") is a type of "parametric polymorphism".

Quote:
 Original post by snk_kid[ several clarifications on my original post ]

Thanks. At the start of this thread I thought that making such distinctions would be splitting hairs (especially fully going into how Haskell acheives polymorphism), but the conversation has definitely become much more indepth.

Quote:

Sounds to me like he was talking about something like "a.draw(); b.draw();" where a and b do not necessarily have the same type. Which I understand to be parametric polymorphism (single dispatch). Really, it does seem a fine distinction to me in C++, a "mishmash" as you call it. In either case, "fake" is the wrong word. I think maybe the closest you'll find to fake polymorphism is in C where people sometimes do:
void drawFoo(Foo *f);
void drawBar(Bar *b);

##### Share on other sites
Quote:
Original post by Way Walker
Quote:
 Original post by Emmanuel DelogetMost of the time you'll use inheritance polymorphism here - your node type will inherit the SceneNode class and draw() will be a virtual method in SceneNode. So no, it's not parametric polymorphism :)

The article you linked to points out that "sub-type polymorphism" (I assume that's what you're refering to as "inheritance polymorphism") is a type of "parametric polymorphism".

The article states:
Quote:
 Using parametric polymorphism, a function or a data type can be written generically so that it can deal equally well with any objects without depending on their type.

Quote:
 In most object-oriented programming languages that support parametric polymorphism, parameters can be constrained to be subtypes of a given type (see #Subtyping polymorphism below and the article on Generic programming).

f : p1 x .. x pn -> r
If you consider p1 to be the object type and p2 to pn fixed, then you have some kind of parametric polymorphism. Now, if you constrain p1 to be either p1 or one of its subtype then yes, you end up with subtype polymorphism as a particular type of parametric polymorphism. Theorically, you're right. But I'm not going to update my C++ teaching slides with this information [smile]

Quote:
Original post by Way Walker
Quote:
 Original post by snk_kid[ several clarifications on my original post ]

Thanks. At the start of this thread I thought that making such distinctions would be splitting hairs (especially fully going into how Haskell acheives polymorphism), but the conversation has definitely become much more indepth.

Yep :) (that's why I won't update my slides)

Quote:
Original post by Way Walker
Quote:

Sounds to me like he was talking about something like "a.draw(); b.draw();" where a and b do not necessarily have the same type. Which I understand to be parametric polymorphism (single dispatch). Really, it does seem a fine distinction to me in C++, a "mishmash" as you call it. In either case, "fake" is the wrong word. I think maybe the closest you'll find to fake polymorphism is in C where people sometimes do:
void drawFoo(Foo *f);
void drawBar(Bar *b);

If you have two functions with the same name in two different and completely unrelated objects, you may call this parametric polymorphism (again: f : p1 x .. x pn -> r, where p1 is a constrained type representing the object type - see my previous comment) but it sounds like a language abuse [smile]

##### Share on other sites
Way Walker    745
Quote:
 Original post by Emmanuel DelogetIf you have two functions with the same name in two different and completely unrelated objects, you may call this parametric polymorphism (again: f : p1 x .. x pn -> r, where p1 is a constrained type representing the object type - see my previous comment) but it sounds like a language abuse [smile]

C++ or English abuse? [smile]

##### Share on other sites
snk_kid    1312
Quote:
Original post by Emmanuel Deloget
Quote:
Original post by Way Walker
Quote:

Sounds to me like he was talking about something like "a.draw(); b.draw();" where a and b do not necessarily have the same type. Which I understand to be parametric polymorphism (single dispatch). Really, it does seem a fine distinction to me in C++, a "mishmash" as you call it. In either case, "fake" is the wrong word. I think maybe the closest you'll find to fake polymorphism is in C where people sometimes do:
void drawFoo(Foo *f);
void drawBar(Bar *b);

If you have two functions with the same name in two different and completely unrelated objects, you may call this parametric polymorphism (again: f : p1 x .. x pn -> r, where p1 is a constrained type representing the object type - see my previous comment) but it sounds like a language abuse [smile]

I made a typo earlier i said "not sub-type polymorphism" i was meant to say "not parametric polymorphism" but at the end of the day Shamino's last two posts just confused me so i'm not exactly sure what he/she is trying to say.

About what Way Walker said this not quite parametric polymorphism, it's valid in the current C++ templates model (things probably change when Concepts are added) but this isn't valid in a language with true parametric polymorphism unless either draw is a polymorphic function (parametric polymorphism) or you add some kind of ad-hoc polymorphism and/or you have some form of bounded parametric polymorphism.

What Emmanuel Deloget mentioned this is known as F-bounded parametric polymorphism thats what you have in OO Generic languages like C# 2.0. Haskell's type classes are really more like giving haskell a form of bounded parametric polymorphism rather than ad-hoc polymorphism (overloading) it depends on the point of view you look at it and it's why you'll read that haskell's ad-hoc polymorphism support is *less ad-hoc* than usual.

[Edited by - snk_kid on March 15, 2006 4:42:12 PM]

## Create an account

Register a new account