IDC资讯中心
除了j#外，所有微软支持的.net开发语言现在均支持运算符重载，因此纯粹为c#简化写法一样特性现已成为一种.net开发中值得研究的一项重要语言特性。有人认为运算符重载其实就是简化写法，满足模拟基本类型操作的小功能，没有必要深究。但我觉得要多思考一层，为什么我们总希望模拟基本类型的操作？因为运算符重载能够将操作中缀化，能够自动推测静态过程的主体。
首先是操作中缀化。函数调用其实是一种前缀操作，函数（代表操作）总是在参数（代表操作数）之前写出。这样执行序列操作时运行的顺序其实和书写的顺序相反：
h(x，y)
g(h(x, y), z)
f(g(h(x, y), z), w)
序列运行的顺序是h->g->f但是却要反过来写，二元参数距离函数名越来越远。我们按照计算机执行的顺序思考，却要反过来写，多少有些不爽。成员函数与扩展方法的写法则是将操作数（对象）写在前面：
x.h(y)
x.h(y).g(z)
x.h(y).g(z).f(w)
这样就将书写的顺序正过来了。这是一个甚好的方案，但是在不具备扩展方法的今天，有些事情是成员函数做不了的。比如在我的vbf里，我希望functor<t, bool>可以进行and, or等逻辑运算，而functor<t, int>之间只能进行算术运算，functor<t, string>之间只能进行连接运算，而且规则还不一样……但是成员函数没有根据类型参数选取不同重载的能力，也就是说.net泛型无法进行特化操作。在.net中具有编译期类型判定的机制只有两个：函数根据参数类型的重载和用户自定义隐式转换（相当于根据返回类型重载）。我们可以用functor<,>类型的静态方法来实现根据类型参数不同的不同重载。但是静态方法不但要写全类型的名字，还是前缀操作，使用起来让人甚为不爽，这时就会发现，运算符重载是我们梦寐以求的东西。
type.op_operator(x, y) 静态方法
x op y 运算符写法
以上两种是等价的，可以看到运算符重载不仅可以通过x,y的类型推测静态方法的调用主体type，还可以将操作转化为中缀写法——比后缀更适合表现二元运算。既然这么完美，我们能不能这样写呢？
class functor(of t, u)
public shared operator and(x as functor(of t, boolean), y as functor(of t, boolean)) _
as functor(of t, boolean)
end operator
end class
很遗憾，这样会编译错误。作为运算符重载过程，其参数至少有一个必须是定义运算符的类型。在编译器看来，必须是functor(of t, u)，两个类型参数都必须是该泛型类定义的。就在我对此大感抱怨时，我偶然在c#编译器的源代码（见rotor）中看到了它识别运算符的规则，其中并没有这些限制，只有两条规则——方法必须是静态的，特定名称的方法；方法必须带有specialname属性。那么我们完全可以骗过编译器，不用它提供的operator关键字来声明运算符重载过程，而是使用自己编写特定名称的方法，并加以specialname的手法来打造运算符重载过程：
imports system.runtime.compilerservices
class functor(of t, u)
<specialname()> _
public shared function op_bitwiseand(x as functor(of t, boolean), y as functor(of t, boolean)) _
as functor(of t, boolean)
end function
end class
system.runtime.compilerservices.specialnameattribute是一个指示编译器为声明成员添加specialname的特殊属性，c#和vb编译器都支持。op_bitwiseand是vb和c#等语言所识别的与操作运算符过程名称。这样写完以后编译成类库，再以引用dll的方式引用它，你就会看到编译器将他识别成了我们要的运算符重载过程。当你在functor<t, int>这样的类型上使用and操作时，编译器会告诉你不支持该运算符，仅在functor<t, bool>上才能进行这一操作，编译错误信息准确无误，真是太棒了。
在我们结束前，我们还可以看看如此手工打造还能突破哪些编译器人为的限制：
可重载protected和private的运算符（尽管这样做几乎没有意义）
可不成对重载比较运算符（=, >, >=, <=, <, <>）
可以让移位运算符的第二个操作数不是int（>>和<<样子很好看，但是有了这个限制我们就不能拿它来干别的事情，现在好了）
可以在c#中重载仅vb支持的运算符，也可以在vb中重载仅c#支持的运算符（当然要到对方语言中才能生效）
可以让用户自定义显式转换支持泛型类型参数之间更加神奇的写法
用了这种手法，似乎还可以重载诸如operator+(int, int)之类的运算符，但它们并不能生效。
.net语言编译器中每一项特性，都可能有隐藏在其表面之下的深层次用途。善加研究后常能发现原来所认识不到的功能。我当然不是在推荐大家乱用运算符重载，只是一种思考，一种新的灵感。
