run-time polymorphism VS compile-time polymorphism

Question

2.00/5 (1 vote)

See more:

"Overriding is the example of run-time polymorphism"
"Overloading is the example of compile-time polymorphism."

My confusion is : What is 'that' resolved at runtime ? (overriding)
What is 'that' resolved at compile-time(overloading)

In other words, what is runtine in overriding and what is complile-time in overloading ?
Can't I use overriding at compile-time or vice-versa ?

pLEASE Note : that I understand the meaning of runtime and compile-time....but unable to relate it with the above two statements. HELP !!!

Posted 31-Dec-10 21:23pm

shikhar gilhotra

Add a Solution

3 solutions

Solution 1

Suppose methods void Method(arg a) { } and void Method(arg a, arg b) { }. If you call Method(a);, compiler selects void Method(arg a) { } after analyzing function arguments. Same thing happens with operator overloading.

On the other hand, overriding cannot be resolved until run time since objects haven't initialized yet. Suppose a base class Vehicle with a virtual method virtual void Drive() { }; and derived classes Car, Bicycle with overrided Drive() methods.

See code below:

Vehicle v;

v = new Bicycle();
v.Drive();

v = new Car();
v.Drive();

Compiler demands virtual Drive method and it compiles successfully. The right version of Drive method cannot be determined until run-time since since only at that time Vehicle v is initialized as Bicycle and Car respectively.

Hope this helps.

Posted 31-Dec-10 23:04pm

dmageiras

Solution 3

in compile time polymosphism, function calling is done at compile time i.e function calls is resolved at compile time. ex function overloading

whereas in run time polymorphism, function calling is done at run time i.e function calls is resolved at runtime . ex function overriiding.

Posted 28-Mar-14 23:09pm

neeraj2370

Comments

[no name] 29-Mar-14 9:21am

This question was sufficiently answered 3 years ago. Why are you answering it again?

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2011-01-01T00:43:00

There is no polymorphism achieved with overloading. Your second citation is a false statement (source, please!). First one is true.

This is not too hard to validate.
I would explain polymorphism on the level you would understand but it would take a couple of pages of text and may require your feedback and answering further questions.

Let's do the following: first, let's close an issue with overloading. It's quite simple. If you rename all your overloaded names to make them unique, it will not change your code at all. In other words, names do not matter as soon as a compiler can resolve methods by the way they are called without ambiguity. Sometimes it is not possible to say which overloaded method is implied, then compilation shows an error. There is nothing polymorphic about all that.
See also: http://en.wikipedia.org/wiki/Method_overloading[^], pay attention: there is not mentions of polymorphism in this article (naturally).

For the next step. To understand polymorphism you need to understand 4 things:

1) Inheritance: http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)[^]
2) Virtual methods: http://en.wikipedia.org/wiki/Virtual_method[^], to have an idea of the internals (useful!) see also virtual method table: http://en.wikipedia.org/wiki/Virtual_method_table[^]
3) Late binding: http://en.wikipedia.org/wiki/Late_binding[^] (not detailed enough, see also references in this article)
4) Finally, polymorphism: http://en.wikipedia.org/wiki/Polymorphism_(computer_science)[^]

Please don't afraid of too many articles. They provide pretty short conceptual explanation and are good to read (and not to hard to understand). Also, good thing they explain ideas on several languages, so, if you familiar with some of them it may help.

Now, a short answer on "What is 'that' resolved at runtime ? (overriding)".

After some thinking: overriding itself is done during compile time as well: a virtual function in two different classes (relative throw inheritance) is called indirectly, through Virtual Method Table (VMT).
A caller may work with a variable which is known during compile time as a variable of some parent class, but during run time the actual class instance is one of derived class (which is fine due to inheritance). If not VMT (not virtual function), the called method would be the one of the compile-time class, but due to VMT a virtual method called during run-time will be the one of actual run-time reference.

So, while all the methods (virtual or not) are known during compile time, which exactly is called are known only run-time -- late binding. For a final note: planning object-oriented classes needs understanding and planning. Formally making methods virtual per se may introduce no late binding or polymorphism. Again, I recommend reading; see the references below.