LA.NET [EN]

Sep 20

In some languages (ex.: C#), you can customize the way an operator works. For instance, if you take a look at the String type, you’ll notice that it has these peculiar looking methods:

public static bool operator !=(string a, string b);
public static bool operator ==(string a, string b);

What you’re seeing here is known as operator overloading. Since the String class introduced these methods, you can write the following code to compare strings (btw, when comparing strings, you probably should be more explicit so that someone  that reads your code in the future knows exactly which type of comparison you’re performing):

String str1 = "hi";
String str2 = "hi";
Console.WriteLine( str2 == str1);

Operator overloading isn’t a CLR feature, but a compiler feature. In other words, the compiler is responsible for mapping the operators used in the source code into a method call which can be understood by the CLR. Now, in theory,you’re probably thinking that you can call the static method shown before directly:

Console.WriteLine(String.operator==(str1,str2));

But no, the truth is that you can’t do that (if you try, you’ll get a compiler error which says something like “invalid term: operator”). Even though the CLR doesn’t understand operators, it does specify how languages should expose operator overloads. If a language decides to support operator overload, then it must follow the CLR defined syntax and it must generate methods which match the expected signature. In the case of the == operator, the compiler is supposed to generate an op_Equality method. In case you’re thinking of trying to call that method directly from C#, don’t: you’ll end up getting a compilation error saying that you cannot access the op_Equality method directly.

Before we proceed, you should probably take a look at the complete method name list from here. If you’ve checked it, then you’ve probably noticed that the table has an extra column, called Name or alternative method. When I said that the C# compiler generated a special method for the operator overload, I didn’t mention one important detail: besides respecting the name defined by the CLR, it will also set a flag in the metadata of the method saying that this is a special method which can be used “as an operator”.

When you’re writing code from  a language which doesn’t support operator overloading, you can still introduce the op_XXX methods. Now, the problem is that you also need to have the special flag applied to that method. If you don’t have it, then you won’t be able to use the operator when consuming the type from, say C#. And that’s one of the reasons why you have the friendly name column in that table. MS recommends that you add those methods when you overload operators so that you can always perform the intended operation (as you might expect, these methods will always redirect to the adequate op_XXX methods). I believe MS could have done better here, but  we have to live with what we have, right? And I guess that’s it for now. Stay tuned for more.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>