C#中==操作符存在的缺陷

标签：这一   lock   避免   就会   string   null   .com   block   实现   

　　==操作符因为语法简洁而备受欢迎，但它本身也存在着局限性，比如继承或泛型问题。下面让我们依次来看看吧。

1、==和继承性问题

　　关于==运算符在继承时存在的问题，我们以String类型为例进行说明。

 static void Main(string[] args)
        {
            string str = "hello";
            string str1 = string.Copy(str);

            Console.WriteLine(ReferenceEquals(str, str1));
            Console.WriteLine(str.Equals(str1));
            Console.WriteLine(str == str1);
            Console.WriteLine(object.Equals(str, str1));
            Console.Read();
        }

　　运行上面代码，依次产生：False、True、True、True。该结果很容易解释，除了ReferenceEquals方法进行引用比较之外，其他三种比较方法均是值比较。

　　现在让我们稍微修改一下上述代码，如下所示：

static void Main(string[] args)
        {
            Object str = "hello";
            Object str1 = string.Copy(str);

            Console.WriteLine(ReferenceEquals(str, str1));
            Console.WriteLine(str.Equals(str1));
            Console.WriteLine(str == str1);
            Console.WriteLine(object.Equals(str, str1));
            Console.Read();
        }

 　　再次运行上面代码，结果为：False、True、False、True。和上面的结果进行比较，可以发现，只有==操作符的结果发生了改变，这是为什么呢？

　　原因就在于==相当于一个静态方法，而静态方法不可能是virtual的，本例中当用==进行比较时，比较的是两个Object类型的变量，尽管我们知道str和str1实际是String类型的，但编译器并没有意识到这一点。我们应该牢记的一点就是：对于非虚方法的调用而言，具体调用哪个实现是在编译时期就已经做出决定了。具体到我们的例子，就是说，我们声明了Object类型的两个变量str和str1，那么编译器就会生成比较Object类型的代码。而Object类中是没有==操作符的重载版本实现的，因此，==将进行引用相等性比较，因str和str1是两个不同的实例对象，故返回False。

　　由于在面临继承时的无能为力，故此是不应选择==，而应使用Equals方法进行判等。接下来看一下Equals方法是如何解决这个问题的。

　　显然，当使用Equals方法进行判等测试时，无论调用的是str.Equals还是object.Equals方法，最终调用的都是String类型的override版本实现，故总能计算出我们预期的结果。因此，在存在继承问题时，应使用Equals方法进行判等，而不是==操作符。

　　最后，从本例中可以看到，当我们将==操作符的操作数强转到Object类型时，它将进行引用相等性测试，总是和ReferenceEquals的结果保持一致，因此，一些开发者就使用这种方式来比较引用相等性，但这样做的一个缺点在于：其他的开发者在读到这样的代码片段时可能产生疑惑。因此在比较引用相等性时最好总是使用ReferenceEquals方法。

2、==和泛型问题

　　==的另一个缺陷就是不能和泛型很好地工作在一起。考虑下面的代码：

static void Equals(T a, T b)
{
    Console.WriteLine(a == b);
}

 　　上面代码的逻辑很简单，就是使用==比较两个T类型的对象。但是编译上述代码将报错：

　　之所以报上面的错误，是因为T可能代表任意类型，包括基元类型、值类型和引用类型。无法确定传递的类型是否实现了==操作符重载。

　　在C#中，对于泛型类型，我们无法施加这样的约束，即强制要求传入的泛型类型T实现==的重载。

　　现在，我们能够构建代码，仅有的一个问题就是：Equals被限定在仅能接受引用类型，而不能接受值类型。

　　现在，让我们还是以之前的字符串比较为例，

class Program
{
    static void Main(string[] args)
    {
        Object str = "hello";
        Object str1 = string.Copy((string)str);

        Equals(str, str1);
    }

    static void Equals(T a, T b) where T : class
    {
        Console.WriteLine(a == b);
    }
}

　　现在，猜测一下上面代码的输出结果，是true还是false ？如果我们回想起String类型定义了==操作符的重载实现，那么很可能猜测上面代码的结果为true，但实际运行结果却显示false，这是为何呢？此时很直观的猜测就是==操作符计算的是引用判等，而非值判等。下面让我们看看究竟发生了什么。

　　上面的代码中，尽管通过where T : class语句限定使得编译器知道它能对传入的任何类型应用==操作符进行判等性测试，对应到本例T就是String类型，而且String类型提供了==的重载实现，但编译器并不晓得泛型类型T是否重载了==操作符，因此，它假定T没有重载==。编译器编译代码时假定调用的是Object基类==操作符，因此，==操作符进行引用判等性测试。

　　应该始终牢记一点：在对泛型类型T使用==操作符时，编译器不会使用类型T定义的==运算符重载，相反，它会将T视为Object类型，并调用Object基类的==操作符方法。

　　接下来让我们看下Equals方法如何解决上面的问题。

static void Equals(T a, T b)
{
   Console.WriteLine(object.Equals(a,b));
}

 　　可以看出，我们移除了泛型方法的class限定语句，因为能在任何类型上调用Object.Equals方法，之所以使用static限定，是为了避免发出调用的实例对象为null，可以看出上面的泛型方法对值类型和引用类型均奏效。

　　我们再次运行上面的代码，结果显示True。这是因为Object.Equals方法在运行时将调用它的override版本实现，本例中override版实现的定义位于String类型中，该实现进行值判等性测试。

C#中==操作符存在的缺陷

标签：这一   lock   避免   就会   string   null   .com   block   实现   

原文地址：https://www.cnblogs.com/lian--ying/p/9537711.html