Equals
in [CSharp]
|
From: shapper on 1 Oct 2009 06:28 Hello, Very often in some code I see the use of Equals instead of ==: Equals(context.PropertyValue, null) or Average.Equals(8.5) Is there any difference between using == or Equals? Should I use Equals? Thanks, Miguel
From: Peter Duniho on 1 Oct 2009 13:03 On Thu, 01 Oct 2009 03:28:11 -0700, shapper <mdmoura(a)gmail.com> wrote: > [...] > Is there any difference between using == or Equals? Yes. > Should I use Equals? It depends on what behavior you want. If there is an == operator overload, and if you are using variables typed as the actual type for which the overload you want to use is defined, then the two should be the same. But otherwise, calling the Equals() method is generally preferred because it provides reliable behavior regardless of the declared type of the variables being used. The == overload used is determined at compile-time, without run-time type information about the objects being compared, while the Equals() method called, being a virtual method in the Object class, is determined at run-time based on the type of the objects being compared. Very rarely, you _don't_ want the polymorphic behavior of Equals(). For example, using the == operator is a shortcut for calling the Object.ReferenceEquals() method, as long as the two variables being used are both declared as System.Object types (not usually the case, but it does come up). IMHO, polymorphic types with Equals() method overrides and the == operator being overloaded don't mix very well, because of this disparity. When both have been done, it can lead to some subtle bugs. And in fact, you do have to be pretty careful when dealing with System.String objects to make sure you're using a comparison that produces the expected results in a given context. But, as long as you remember to only ever use the == operator in a context where you know the exact type of the objects being compared and that type is the type of the variables being compared, you should be fine. Eric Lippert's most recent blog post actually touches on this, somewhat tangentially, as part of a discussion on the string interning behavior in ..NET: http://blogs.msdn.com/ericlippert/archive/2009/09/28/string-interning-and-string-empty.aspx Pete
From: shapper on 1 Oct 2009 16:54 On Oct 1, 6:03 pm, "Peter Duniho" <no.peted.s...(a)no.nwlink.spam.com> wrote: > On Thu, 01 Oct 2009 03:28:11 -0700, shapper <mdmo...(a)gmail.com> wrote: > > [...] > > Is there any difference between using == or Equals? > > Yes. > > > Should I use Equals? > > It depends on what behavior you want. > > If there is an == operator overload, and if you are using variables typed > as the actual type for which the overload you want to use is defined, then > the two should be the same. But otherwise, calling the Equals() method is > generally preferred because it provides reliable behavior regardless of > the declared type of the variables being used. > > The == overload used is determined at compile-time, without run-time type > information about the objects being compared, while the Equals() method > called, being a virtual method in the Object class, is determined at > run-time based on the type of the objects being compared. > > Very rarely, you _don't_ want the polymorphic behavior of Equals(). For > example, using the == operator is a shortcut for calling the > Object.ReferenceEquals() method, as long as the two variables being used > are both declared as System.Object types (not usually the case, but it > does come up). > > IMHO, polymorphic types with Equals() method overrides and the == operator > being overloaded don't mix very well, because of this disparity. When > both have been done, it can lead to some subtle bugs. And in fact, you do > have to be pretty careful when dealing with System.String objects to make > sure you're using a comparison that produces the expected results in a > given context. But, as long as you remember to only ever use the == > operator in a context where you know the exact type of the objects being > compared and that type is the type of the variables being compared, you > should be fine. > > Eric Lippert's most recent blog post actually touches on this, somewhat > tangentially, as part of a discussion on the string interning behavior in > .NET:http://blogs.msdn.com/ericlippert/archive/2009/09/28/string-interning... > > Pete Thank you Pete more the explanation and for the link of the Eric Lippert's blog post. It is more clear now ... Thank You, Miguel
From: Ben Voigt [C++ MVP] on 2 Oct 2009 18:00 > The == overload used is determined at compile-time, without run-time type > information about the objects being compared, while the Equals() method > called, being a virtual method in the Object class, is determined at > run-time based on the type of the objects being compared. as a result, testing x == null will work ok, while x.Equals(y) is going to be trouble if x might be null
|
Pages: 1 Prev: C# and Data Concurrency Next: Suspend DataGridView whilst updating a BindingList datasource |