C # разница между == и Equals ()
На основании сообщения Rex, о котором он упомянул:
Stream.continually(input.read(buffer)).takeWhile(_ != -1).foreach(md.update(buffer, 0, _))
Вы должны заменить строку var readLen +, а {...} с ней, она дает тот же результат.
Как упоминал Рекс, он работает с scala 2.8.
4 ответа
Когда == используется в выражении объекта типа , оно будет преобразовано в System.Object.ReferenceEquals .
Equals является просто виртуальным методом и ведет себя как таковой, поэтому будет использоваться переопределенная версия (которая для типа string сравнивает содержимое).
== и . Эквиваленты зависят от поведения, определенного в фактическом типе, и фактического типа при вызове сайт. Оба являются просто методами / операторами, которые могут быть переопределены для любого типа и любого поведения, которого пожелает автор. Исходя из своего опыта, я нахожу, что люди часто реализуют . Равен для объекта, но пренебрегать реализацией оператора == . Это означает, что .Equals будет фактически измерять равенство значений, в то время как == будет измерять, являются ли они одной и той же ссылкой.
Когда я работаю с новым типом, определение которого находится в потоке, или пишу универсальные алгоритмы, я считаю, что передовой практикой является следующее
- Если я хочу сравнить ссылки в C #, я использую
Object.ReferenceEqualsнапрямую (не требуется в общем случае) - Если я хочу сравнить значения, я использую
EqualityComparer.Default
В некоторых случаях, когда я чувствую использование == является неоднозначным. Я явно буду использовать Object.Reference , равный в коде для устранения неоднозначности.
Эрик Липперт недавно сделал сообщение в блоге на тему, почему в CLR есть 2 метода равенства. Это стоит прочитать
Я немного смущен здесь. Если тип времени выполнения Content имеет тип string, то оба == и Equals должны возвращать true. Однако, поскольку это не так, то тип контента во время выполнения не является строкой, и вызов Equals для него делает ссылочное равенство, и это объясняет, почему Equals («энергетическая атака») терпит неудачу. Однако во втором случае решение о том, какой перегруженный == статический оператор следует вызывать, принимается во время компиляции, и это решение выглядит как == (строка, строка). это говорит мне о том, что Content обеспечивает неявное преобразование в строку.
При сравнении ссылки на объект со строкой (даже если ссылка на объект ссылается на строку), особое поведение оператора == , определенного для класса строки, игнорируется.
Обычно (когда не имеет дело со строками, то есть), Equals сравнивает значения , тогда как == сравнивает ссылки на объекты .
Если два объекта, которые вы сравниваете, ссылаются на один и тот же точный экземпляр объекта, то оба будут возвращать истину, но если один имеет одинаковое содержимое и поступил из другого источника (это отдельный экземпляр с одинаковыми данными), только Equals будет верните истину. Однако, как отмечено в комментариях, строка - это особый случай, поскольку она переопределяет оператор == , так что при работе исключительно со ссылками на строки (а не ссылками на объекты) сравниваются только значения, даже если они отдельные случаи. Следующий код иллюстрирует тонкие различия в поведении:
string s1 = "test";
string s2 = "test";
string s3 = "test1".Substring(0, 4);
object s4 = s3;
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s2), s1 == s2, s1.Equals(s2));
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s3), s1 == s3, s1.Equals(s3));
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s4), s1 == s4, s1.Equals(s4));
Вывод:
True True True
False True True
False False True