1

C# I'm trying to compare two different objects (I'm only comparing identical subfields). But I have another place where there's a check against null. Now I have a problem, it falls through to comparing the two different objects, and that blows up because it's not expecting null. I tried to put a new method to compare against object, but it doesn't want to choose that one.

Is it standard practice when overloading operators == or != to check either for null first? Or is there some way to shortcut a comparison to null?

Lee Louviere
  • 5,162
  • 30
  • 54

3 Answers3

3

Yes. You should check for null in your overload. And if you overload ==, you must overload !=, and you should GetHashCode() and Equals().

drdwilcox
  • 3,833
  • 17
  • 19
2

It is standard practice to check for null in equality operators. Take String for example:

public static bool operator ==(string a, string b)
{
    return string.Equals(a, b);
}

public static bool Equals(string a, string b)
{
    return a == b || (a != null && b != null && string.EqualsHelper(a, b));
}
StriplingWarrior
  • 151,543
  • 27
  • 246
  • 315
1

You should not overload == it leads to code that is unintuitive. Just stick to overriding Equals (and GetHashCode)

Taken from Overloading operator== versus Equals() (Samuel Neff's answer)

When you have the expression

x == y

The method that will be used to compare variables x and y is decided at compile time. This is operator overloading. The type used when declaring x and y is used to define which method is used to compare them. The actual type within x and y (i.e., a subclass or interface implementation) is irrelevant. Consider the following.

object x = "hello"; object y = 'h' + "ello"; // ensure it's a different reference
x == y // evaluates to FALSE

and the following

string x = "hello"; string y = 'h' + "ello"; // ensure it's a different reference
x == y // evaluates to TRUE

This demonstrates that the type used to declare the variables x and y is used to determine which method is used to evaluate ==.

By comparison, Equals is determined at runtime based on the actual type within the variable x. Equals is a virtual method on Object that other types can, and do, override. Therefore the following two examples both evaluate to true.

object x = "hello"; object y = 'h' + "ello"; // ensure it's a different reference
x.Equals(y) // evaluates to TRUE

and the following

string x = "hello"; string y = 'h' + "ello"; // ensure it's a different reference
x.Equals(y) // also evaluates to TRUE
Community
  • 1
  • 1
Rich O'Kelly
  • 41,274
  • 9
  • 83
  • 114
  • I don't believe it is *necessarily true* that `"hello"` and `'h' + "ello"` create different object as the compiler has the ability to optimize/fold these away. (C#3 does this optimization for `string + string`, but does not seem to do this for `char + string`. However, I doubt it is against specification to perform such an optimization, if deemed useful.) –  Nov 17 '11 at 23:55
  • I'm not sure I agree with Samuel Neff's answer. overloading == allows programmers to write intuitive code. Rarely do we resort to comparison of at the `object` level of two items, and in that case, it makes sense to use `.Equals()`. Yes, you can get strange results, but that's no reason to abandon a very common idiom. – drdwilcox Nov 18 '11 at 00:09