Click here to Skip to main content
14,694,017 members
Please Sign up or sign in to vote.
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 !!!

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 = new Car();

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.
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:[^], 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:[^]
2) Virtual methods:[^], to have an idea of the internals (useful!) see also virtual method table:[^]
3) Late binding:[^] (not detailed enough, see also references in this article)
4) Finally, polymorphism:[^]

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.
Sandeep Mewara 1-Jan-11 13:27pm
Well explained! Deserves a 5!
Espen Harlinn 28-Feb-11 15:44pm
Good answer, my 5
Thank you.
Shikhar Singh 27-Feb-14 6:23am in this article , there is a mention of static polymorphism. And even in the Article , under the definition of Ad Hoc polymorphism , it gives the example of Function Overloading. So how can you say that no polymorphism is achieved with overloading??
What do you mean "how can I say"? I am not a brainless idiot who trust everything which is written. I have my own brain and some knowledge/understanding. I someone wants to convince me in something, this "someone" should provide some convincing logical evidence.
I explained what "overloading" is, and that it is fully equivalent to having different method names, in which case no one would call it "polymorphism".
Polymorphism via "overloading" is just yet another myth. It's sad that this article supports it.
Shikhar Singh 27-Feb-14 9:22am
No offence, I was just confused. But yet another question arises in my mind that what about constructor overloading ? You cant change the name of a constructor.
Sergey Alexandrovich Kryukov 27-Feb-14 11:00am
Thank you for understanding. (Please, what are you talking about, what offense? No, no hard feeling, not even close. In terms of nice way of personal communications, you have been perfectly correct. I hope I also did not offend anyone...)

Of course you cannot change the name of the constructor. Look, there is no "overloading", because nothing is "loaded". This is just a bad term coined, confused many. It's just the syntax where different methods have the same name; and the compiler can resolve them. But in case of constructors, they have to be of the same name. That's all.

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.
[no name] 29-Mar-14 9:21am
This question was sufficiently answered 3 years ago. Why are you answering it again?

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

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900