In simple words, method overloading is having multiple methods in a class with the same name but different argument types and numbers. For example: chandraPrakash(double a, double b); chandraPrakash(double a); chandraPrakash(double a, float b); chandraPrakash(int a, float b, int c); Now you will be able to call the same method four different ways. Based on what arguments and how many arguments you use to call the method, different methods will be invoked. You need to have a separate definition for each of these methods.

nepalnepaliko · Oct 27, 2015 2:17 PM

Yo chandra prakash.  Since you deleted my post, I'm editing this one.  Why don't you delete this post too? Last edited: 28-Oct-15 03:52 AM

nepalnepaliko · Oct 27, 2015 2:20 PM

अब म भाइ भन्छु है चन्द्र प्रकाश ! अब भाइ त भनि हाले, गालि न गर्नु नि ! जे भए पनि नेपाली हो नि, ठुला ले साना लाइ माया अनि साना ले ठुला लाइ आदर संस्कार त गर्ने पर्यो है, त्यो त हामि नेपाली को चिनारी नै हो ! भाइ ले मुख छाड्छउ कि जस्तो लागेर यत्ति भूमिका बाधेको किन कि भाइ को एक दुइ कमेन्ट पढेको थिए, आफु लाइ नै लाज लाग्यो त्यो पढेर ! फेरी हिरो किन पल्टिएको भन्ने न सोच है त भाइ.. म पनि तिमि अहिले चढेको नाउ चढेर&nbsp;यहाँ आइ पुगेको हो, तिमि ले हिड्न खोज्दै गरेको बाटो हिडेर यहाँ आइपुगेको हो ! हिरो पट्टक्कै हुन खोजेको हैन नि ! प्लिज फोर्गिव मि इफ आइ एम रिउड! अब प्रस्न को जवाफ दिनु भन्दा पनि पहिला, भाइ लाइ एउटा सुझाब दिन्छु, हुन त हामि नेपाली लाइ सुझाब त पटक्कै पच्दैन, पक्का गालि भरिएको जवाफ पाउछु होला ! तर पनि अर्ति भनेको घर्ति को पनि लिनु पर्छ ! मलाई एउटा अत्ति न जान्ने अनि अत्ति अनपढ जस्तै ठानेर मेरो सुझाब तुरुन्त आफ्नो जीवन मा प्रयोग गर है त भाइ ! PLEASE STUDY !!! PLEASE DO LABOR BY YOURSELF !!! STOP MAKING YOURSELF AS A JOKE !!! IF YOU NEED A TRAINER , WE CAN HELP YOU FIND A GOOD ONE !!! YES !!! YOU MIGHT HAVE TO PAY FOR THE TRAINING !!! BUT I AM PRETTY SURE SOMEBODY WILL SUGGEST YOU A GOOD TRAINER !!! YOU NEED A TRAINER NOW !!! AND DEFINITELY A POSITIVE ATTITUDE AND HARD LABOR!!! PLEASE READ THIS !!!&nbsp; ALL COPIED FROM GOOGLE !!! Method Overloading&nbsp;is a feature that allows a class to have two or more&nbsp;methods&nbsp;having same name, if their argument lists are different. In the last tutorial we discussed constructor&nbsp;overloading&nbsp;that allows a class to have more than one constructors having different argument lists. Overloading Just as a reminder,&nbsp;overloading&nbsp;is what happens when you have two methods with the same name but different signatures. At&nbsp;compile time, the compiler works out which one it's going to call, based on the compile time types of the arguments and the target of the method call. (I'm assuming you're not using&nbsp;dynamic&nbsp;here, which complicates things somewhat.) Now, things can get a little bit confusing sometimes when it comes to resolving overloads... especially as things can change between versions. This article will point out&nbsp;some&nbsp;of the gotchas you might run into... but I'm not going to claim it's an authoritative guide to how overloading is performed. For that, read the specification - but be aware that you may get lost in a fairly complex topic. Overloading interacts with things like type inference and implicit conversions (including lambda expressions, anonymous methods and method groups, all of which can become tricky). All specification references are from the C# 4 spec. This article is also not going to go into the design choices of when it's appropriate and when it's not. I'll give a little advice about when it might be potentially very confusing to use overloading, but anything beyond that will have to wait for another time. I will say that&nbsp;in general&nbsp;I believe overloading should be used for convenience, usually with all overloads ending up calling one "master" method. That's not always the case, but I believe it's the most common scenario which is appropriate. In each example, I'll give a short program which will declare some methods and call one - and then I'll explain what gets called in which version of C#, and why. As I'm not trying to focus on the design decisions but merely the mechanical choices the C# compiler makes, I haven't tried to make the examples do anything realistic, or even given them realistic names: the overloaded method is always&nbsp;Foo, and it will always just print its own signature. Of course the action taken is irrelevant, but it makes it easier to grab the code and experiment with it if you want to. Simple cases Let's start off with a couple of really simple cases, just to get into the swing of things. First, the trivial case where only one overload is possible at all. using&nbsp;System; class&nbsp;Test { &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(int&nbsp;x) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(int&nbsp;x)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(string&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(string&nbsp;y)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Main() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Foo("text"); &nbsp;&nbsp;&nbsp;&nbsp;} } This will print&nbsp;Foo(string y)&nbsp;- there's no implicit string conversion from&nbsp;string&nbsp;(the type of the argument here, "text") to&nbsp;int, so the first method isn't an&nbsp;applicable function member&nbsp;in spec terminology (section 7.5.3.1). Overloading ignores any methods which&nbsp;can't&nbsp;be right when it's deciding which one to call. Let's actually give the compiler something to think about this time... using&nbsp;System; class&nbsp;Test { &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(int&nbsp;x) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(int&nbsp;x)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(double&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(double&nbsp;y)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Main() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Foo(10); &nbsp;&nbsp;&nbsp;&nbsp;} } This time,&nbsp;Foo(int x)&nbsp;will be printed. Both methods are applicable - if we removed the method taking an `int`, the method taking a `double` would be called instead. The compiler decides which one to pick based on the&nbsp;better function member&nbsp;rules (section 7.5.3.2) which look at (amongst other things) what conversions are involved in going from each&nbsp;argument&nbsp;to the corresponding&nbsp;parameter&nbsp;type (int&nbsp;for the first method,&nbsp;double&nbsp;for the second). There are more rules (section 7.5.3.3) to say which conversion is better than the other - in this case, a conversion from an expression of type&nbsp;int&nbsp;to&nbsp;int&nbsp;is better than a conversion from&nbsp;int&nbsp;to&nbsp;double, so the first method "wins". Multiple parameters When there are multiple parameters involved, for one method to "beat" another one it has to be&nbsp;at least as good&nbsp;for each parameter, and&nbsp;better&nbsp;for at least one parameter. This is done on a method-by-method comparison: a method doesn't have to be better than&nbsp;all&nbsp;other methods for any single parameter. For example: using&nbsp;System; class&nbsp;Test { &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(int&nbsp;x,&nbsp;int&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(int&nbsp;x,&nbsp;int&nbsp;y)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(int&nbsp;x,&nbsp;double&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(int&nbsp;x,&nbsp;double&nbsp;y)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(double&nbsp;x,&nbsp;int&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(double&nbsp;x,&nbsp;int&nbsp;y)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Main() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Foo(5,&nbsp;10); &nbsp;&nbsp;&nbsp;&nbsp;} } Here the first method (Foo(int x, int y)) wins because it beats the second method on the second parameter, and the third method on the first parameter. If no method wins outright, the compiler will report an error: using&nbsp;System; class&nbsp;Test { &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(int&nbsp;x,&nbsp;double&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(int&nbsp;x,&nbsp;double&nbsp;y)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(double&nbsp;x,&nbsp;int&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(double&nbsp;x,&nbsp;int&nbsp;y)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Main() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Foo(5,&nbsp;10); &nbsp;&nbsp;&nbsp;&nbsp;} } Result: error&nbsp;CS0121:&nbsp;The&nbsp;call&nbsp;is&nbsp;ambiguous&nbsp;between&nbsp;the&nbsp;following&nbsp;methods&nbsp;or properties:&nbsp;'Test.Foo(int,&nbsp;double)'&nbsp;and&nbsp;'Test.Foo(double,&nbsp;int)' Inheritance Inheritance can cause a confusing effect. When the compiler goes looking for instance method overloads, it considers the compile-time class of the "target" of the call, and looks at methods declared there. If it can't find anything suitable, it then looks at the parent class... then the grandparent class, etc. This means that if there are two methods at different levels of the hierarchy, the "deeper" one will be chosen first, even if it isn't a "better function member" for the call. Here's a fairly simple example: using&nbsp;System; class&nbsp;Parent { &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;void&nbsp;Foo(int&nbsp;x) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Parent.Foo(int&nbsp;x)"); &nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp;&nbsp; class&nbsp;Child&nbsp;:&nbsp;Parent { &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;void&nbsp;Foo(double&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Child.Foo(double&nbsp;y)"); &nbsp;&nbsp;&nbsp;&nbsp;} } &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; class&nbsp;Test { &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Main() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Child&nbsp;c&nbsp;=&nbsp;new&nbsp;Child(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c.Foo(10); &nbsp;&nbsp;&nbsp;&nbsp;} } The target of the method call is an expression of type&nbsp;Child, so the compiler first looks at the&nbsp;Child&nbsp;class. There's only one method there, and it's applicable (there's an implicit conversion from&nbsp;int&nbsp;to&nbsp;double) so that's the one that gets picked. The compiler doesn't consider the&nbsp;Parent&nbsp;method at all. The reason for this is to reduce the risk of the&nbsp;brittle base class&nbsp;problem, where the introduction of a new method to a base class could cause problems for consumers of classes derived from it. Eric Lippert has&nbsp;various posts about the brittle base class problem&nbsp;which I can highly recommend. There's one aspect of this behaviour which is&nbsp;particularly&nbsp;surprising though. What counts as a method being "declared" in a class? It turns out that if you&nbsp;override&nbsp;a base class method in a child class, that doesn't count as declaring it. Let's tweak our example very slightly: using&nbsp;System; class&nbsp;Parent { &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;virtual&nbsp;void&nbsp;Foo(int&nbsp;x) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Parent.Foo(int&nbsp;x)"); &nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp;&nbsp; class&nbsp;Child&nbsp;:&nbsp;Parent { &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;override&nbsp;void&nbsp;Foo(int&nbsp;x) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Child.Foo(int&nbsp;x)"); &nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;void&nbsp;Foo(double&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Child.Foo(double&nbsp;y)"); &nbsp;&nbsp;&nbsp;&nbsp;} } &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; class&nbsp;Test { &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Main() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Child&nbsp;c&nbsp;=&nbsp;new&nbsp;Child(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c.Foo(10); &nbsp;&nbsp;&nbsp;&nbsp;} } Now it&nbsp;looks&nbsp;like you're trying to call&nbsp;Child.Foo(int x)&nbsp;in my opinion - but the above code will actually print&nbsp;Child.Foo(double y). The compiler ignores the overriding method in the child. Given this oddness, my advice would be to&nbsp;avoid overloading across inheritance boundaries... at least with methods where more than one method could be applicable for a given call if you flattened the hierarchy. You'll be glad to hear that the rest of the examples on this page don't use inheritance. Return types The return type of a method is&nbsp;not&nbsp;considered to be part of a method's signature (section 3.6), and an overload is determined&nbsp;before&nbsp;the compiler checks whether or not the return type will cause an error in the wider context of the method call. In other words, it's not part of the test for an applicable function member. So for example: using&nbsp;System; class&nbsp;Test { &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;string&nbsp;Foo(int&nbsp;x) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(int&nbsp;x)"); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;""; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;Guid&nbsp;Foo(double&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(double&nbsp;y)"); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;Guid.Empty; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Main() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Guid&nbsp;guid&nbsp;=&nbsp;Foo(10); &nbsp;&nbsp;&nbsp;&nbsp;} } Here the overload of&nbsp;string Foo(int x)&nbsp;is chosen and&nbsp;then&nbsp;the compiler works out that it can't assign a&nbsp;string&nbsp;to a variable of type&nbsp;Guid. On its own, the&nbsp;Guid Foo(double y)&nbsp;would be fine, but because the other method was better in terms of argument conversions, it doesn't have a chance. Optional parameters Optional parameters, introduced into C# 4, allow a method to declare a default value for some or all of its parameters. The caller can then omit the corresponding arguments if they're happy with the defaults. This affects overload resolution as there may be multiple methods with a different number of parameters which are all applicable. When faced with a choice between a method which requires the compiler to fill in optional parameter values and one which doesn't, if the methods are otherwise "tied" (i.e. normal argument conversion hasn't decided a winner), overload resolution will pick the one where the caller has specified all the arguments explicitly: using&nbsp;System; class&nbsp;Test { &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(int&nbsp;x,&nbsp;int&nbsp;y&nbsp;=&nbsp;5) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(int&nbsp;x,&nbsp;int&nbsp;y&nbsp;=&nbsp;5)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(int&nbsp;x) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(int&nbsp;x)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Main() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Foo(10); &nbsp;&nbsp;&nbsp;&nbsp;} } When considering the first method, the compiler would need to fill in the argument for the&nbsp;y&nbsp;parameter using the default value - whereas the second method doesn't require this. The output is therefore&nbsp;Foo(int x). Note that this is purely a yes/no decision: if two methods both require default values to be filled in, and they're otherwise tied, the compiler will raise an error: using&nbsp;System; class&nbsp;Test { &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(int&nbsp;x,&nbsp;int&nbsp;y&nbsp;=&nbsp;5,&nbsp;int&nbsp;z&nbsp;=&nbsp;10) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(int&nbsp;x,&nbsp;int&nbsp;y&nbsp;=&nbsp;5,&nbsp;int&nbsp;z&nbsp;=&nbsp;10)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(int&nbsp;x,&nbsp;int&nbsp;y&nbsp;=&nbsp;5) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(int&nbsp;x,&nbsp;int&nbsp;y&nbsp;=&nbsp;5)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Main() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Foo(10); &nbsp;&nbsp;&nbsp;&nbsp;} } This call is ambiguous, because the one argument which&nbsp;has&nbsp;been given is fine for both methods, and both require extra arguments which would be filled in from default values. The fact that the first method would need two arguments to be defaulted and the second would only need one is irrelevant. Just to be clear, this tie breaking&nbsp;only&nbsp;comes in after the methods have been compared to each other using the pre-C# 4 rules. So, let's change our earlier example a little: using&nbsp;System; class&nbsp;Test { &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(int&nbsp;x,&nbsp;int&nbsp;y&nbsp;=&nbsp;5) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Console.WriteLine("Foo(int&nbsp;x,&nbsp;int&nbsp;y&nbsp;=&nbsp;5)"); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;static&nbsp;void&nbsp;Foo(<span class="ValueType" styl

RadhaKrishna · Oct 28, 2015 1:24 AM

lol

alece · Oct 28, 2015 7:39 AM

Over Loading is not so important and not commonly used. Try to understand Over riding. It has to do more with object oriented, inheritance implementation. If you do C#, try to understand Protected and Virtual methods

NepaliBhai · Oct 28, 2015 11:00 AM

Over Loading is not so important and not commonly used. Try to understand Over riding. It has to do more with object oriented, inheritance implementation. If you do C#, try to understand Protected and Virtual methods

NepaliBhai · Oct 28, 2015 11:00 AM

@Radhakirshana, Sujhawa ramro lagyo.

Pharsi · Oct 28, 2015 12:02 PM

I do not agree with @NepaliBhai . If you think overloading is not important and not commonly used then I would say you haven't programmed much. Both overloading and overriding are equally important.

randomguy · Oct 28, 2015 12:22 PM