Related
I have a condition in a silverlight application that compares 2 strings, for some reason when I use == it returns false while .Equals() returns true.
Here is the code:
if (((ListBoxItem)lstBaseMenu.SelectedItem).Content.Equals("Energy Attack"))
{
// Execute code
}
if (((ListBoxItem)lstBaseMenu.SelectedItem).Content == "Energy Attack")
{
// Execute code
}
Any reason as to why this is happening?
When == is used on an expression of type object, it'll resolve to System.Object.ReferenceEquals.
Equals is just a virtual method and behaves as such, so the overridden version will be used (which, for string type compares the contents).
When comparing an object reference to a string (even if the object reference refers to a string), the special behavior of the == operator specific to the string class is ignored.
Normally (when not dealing with strings, that is), Equals compares values, while == compares object references.
If two objects you are comparing are referring to the same exact instance of an object, then both will return true, but if one has the same content and came from a different source (is a separate instance with the same data), only Equals will return true. However, as noted in the comments, string is a special case because it overrides the == operator so that when dealing purely with string references (and not object references), only the values are compared even if they are separate instances. The following code illustrates the subtle differences in behaviors:
string s1 = "test";
string s2 = "test";
string s3 = "test1".Substring(0, 4);
object s4 = s3; // Notice: set to object variable!
Console.WriteLine($"{object.ReferenceEquals(s1, s2)} {s1 == s2} {s1.Equals(s2)}");
Console.WriteLine($"{object.ReferenceEquals(s1, s3)} {s1 == s3} {s1.Equals(s3)}");
Console.WriteLine($"{object.ReferenceEquals(s1, s4)} {s1 == s4} {s1.Equals(s4)}");
The output is:
True True True // s1, s2
False True True // s1, s3
False False True // s1, s4
Summary:
Variables
.ReferenceEquals
==
.Equals
s1, s2
True
True
True
s1, s3
False
True
True
s1, s4
False
False
True
== and .Equals are both dependent upon the behavior defined in the actual type and the actual type at the call site. Both are just methods / operators which can be overridden on any type and given any behavior the author so desires. In my experience, I find it's common for people to implement .Equals on an object but neglect to implement operator ==. This means that .Equals will actually measure the equality of the values while == will measure whether or not they are the same reference.
When I'm working with a new type whose definition is in flux or writing generic algorithms, I find the best practice is the following
If I want to compare references in C#, I use Object.ReferenceEquals directly (not needed in the generic case)
If I want to compare values I use EqualityComparer<T>.Default
In some cases when I feel the usage of == is ambiguous I will explicitly use Object.Reference equals in the code to remove the ambiguity.
Eric Lippert recently did a blog post on the subject of why there are 2 methods of equality in the CLR. It's worth the read
http://blogs.msdn.com/ericlippert/archive/2009/04/09/double-your-dispatch-double-your-fun.aspx
== Operator
If operands are Value Types and their values are equal, it returns true else false.
If operands are Reference Types with exception of string and both refer to the same instance (same object), it returns true else false.
If operands are string type and their values are equal, it returns true else false.
.Equals
If operands are Reference Types, it performs Reference Equality that is if both refer to the same instance (same object), it returns true else false.
If Operands are Value Types then unlike == operator it checks for their type first and if their types are same it performs == operator else it returns false.
As far as I understand it the answer is simple:
== compares object references.
.Equals compares object content.
String datatypes always act like content comparison.
I hope I'm correct and that it answered your question.
Firstly, there is a difference. For numbers
> 2 == 2.0
True
> 2.Equals(2.0)
False
And for strings
> string x = null;
> x == null
True
> x.Equals(null)
NullReferenceException
In both cases, == behaves more usefully than .Equals
I would add that if you cast your object to a string then it will work correctly. This is why the compiler will give you a warning saying:
Possible unintended reference comparison; to get a value comparison,
cast the left hand side to type 'string'
Because the static version of the .Equal method was not mentioned so far, I would like to add this here to summarize and to compare the 3 variations.
MyString.Equals("Somestring")) //Method 1
MyString == "Somestring" //Method 2
String.Equals("Somestring", MyString); //Method 3 (static String.Equals method) - better
where MyString is a variable that comes from somewhere else in the code.
Background info and to summerize:
In Java using == to compare strings should not be used. I mention this in case you need to use both languages and also
to let you know that using == can also be replaced with something better in C#.
In C# there's no practical difference for comparing strings using Method 1 or Method 2 as long as both are of type string. However, if one is null, one is of another type (like an integer), or one represents an object that has a different reference, then, as the initial question shows, you may experience that comparing the content for equality may not return what you expect.
Suggested solution:
Because using == is not exactly the same as using .Equals when comparing things, you can use the static String.Equals method instead. This way, if the two sides are not the same type you will still compare the content and if one is null, you will avoid the exception.
bool areEqual = String.Equals("Somestring", MyString);
It is a little more to write, but in my opinion, safer to use.
Here is some info copied from Microsoft:
public static bool Equals (string a, string b);
Parameters
a String
The first string to compare, or null.
b String
The second string to compare, or null.
Returns Boolean
true if the value of a is the same as the value of b; otherwise, false. If both a and b are null, the method returns true.
Just as an addition to the already good answers: This behaviour is NOT limited to Strings or comparing different numbertypes. Even if both elements are of type object of the same underlying type. "==" won't work.
The following screenshot shows the results of comparing two object {int} - values
I am a bit confused here. If the runtime type of Content is of type string, then both == and Equals should return true. However, since this does not appear to be the case, then runtime type of Content is not string and calling Equals on it is doing a referential equality and this explains why Equals("Energy Attack") fails. However, in the second case, the decision as to which overloaded == static operator should be called is made at compile time and this decision appears to be ==(string,string). this suggests to me that Content provides an implicit conversion to string.
There is another dimension to an earlier answer by #BlueMonkMN. The additional dimension is that the answer to the #Drahcir's title question as it is stated also depends on how we arrived at the string value. To illustrate:
string s1 = "test";
string s2 = "test";
string s3 = "test1".Substring(0, 4);
object s4 = s3;
string s5 = "te" + "st";
object s6 = s5;
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s2), s1 == s2, s1.Equals(s2));
Console.WriteLine("\n Case1 - A method changes the value:");
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));
Console.WriteLine("\n Case2 - Having only literals allows to arrive at a literal:");
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s5), s1 == s5, s1.Equals(s5));
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s6), s1 == s6, s1.Equals(s6));
The output is:
True True True
Case1 - A method changes the value:
False True True
False False True
Case2 - Having only literals allows to arrive at a literal:
True True True
True True True
Adding one more point to the answer.
.EqualsTo() method gives you provision to compare against culture and case sensitive.
Really great answers and examples!
I would just like to add the fundamental difference between the two,
Operators such as == are not polymorphic, while Equals is
With that concept in mind, if you work out any example (by looking at left hand and right hand reference type, and checking/knowing if the type actually has == operator overloaded and Equals being overriden) you are certain to get the right answer.
This is due to value equality (equal method) and referential equality(== operator), as the equal method checks the values while the same == is checked the reference.
== operator overriding code available inside the string class on https://referencesource.microsoft.com/
so now it's easier to understand, the equal method also has 2 implementations one from the string class itself and one from the object class. its impact on performance as well I also run some basic code and try to understand the benchmarks.
I am sharing the results below Please correct or advise if I am wrong somewhere. there are 3 cases and I have run the same code for all the cases and this is the result.
case 1: here I am using string. equal method for comparing 2 strings and both the string have the same values. string.equals(a,b)
1st run:5608195 ticks
2nd run:5529387 ticks
3rd run:5622569 ticks
total ticks: 16760151
case 2: here I am using string. equal() method(overloaded one) for comparing 2 strings and both the string have the same values.
a.equals(b)
1st run: 6738583 ticks
2nd run: 6452927 ticks
3rd run: 7168897 ticks
total ticks=20360407
case 3: here I am using the == operator for comparing 2 strings and both the string have the same values.
a==b
1st run: 6652151 ticks
2nd run: 7514300 ticks
3rd run: 7634606 ticks
total ticks=21801057
class Program
{
private static int count;
static string a = "abcdef";
static string b = "abcdef";
static void Main(string[] args)
{
for (int j = 1; j <= 3; j++)
{
Stopwatch sw = new Stopwatch();
sw.Start();
for (int i = 1; i <= 1000; i++)
{
checkString();
}
sw.Stop();
Console.WriteLine(sw.ElapsedTicks);
}
Console.ReadLine();
}
public static void checkString()
{
for (int i = 1; i <= 100000; i++)
{
if (a==b)
count++;
}
}
}
The == token in C# is used for two different equality-check operators. When the compiler encounters that token, it will check whether either of the types being compared has implemented an equality-operator overload for either the specific combination types being compared(*), or for a combination of types to which both types can be converted. If the compiler finds such an overload it will use it. Otherwise, if the two types are both reference types and they are not unrelated classes (either may be an interface, or they may be related classes), the compiler will regard == as a reference-comparison operator. If neither condition applies, compilation will fail.
Note that some other languages use separate tokens for the two equality-check operators. In VB.NET, for example, the = token is used within expressions solely for the overloadable equality-check operator, and Is is used as a reference-test or null-test operator. An to use = on a type which does not override the equality-check operator will fail, as will attempting to use Is for any purpose other than testing reference equality or nullity.
(*)Types generally only overload equality for comparison with themselves, but it may be useful for types to overload the equality operator for comparison with other particular types; for example, int could have (and IMHO should have but didn't) defined an equality operators for comparison with float, so that 16777217 would not report itself equal to 16777216f. As it is, since no such operator is defined, C# will promote the int to float, rounding it to 16777216f before the equality-check operator sees it; that operator then sees two equal floating-point numbers and reports them as equal, unaware of the rounding that took place.
Note that there are two different types of equality in C#
1- Value Equality (For value types like int, DateTime and struct)
2- Reference Equality (For objects)
There are two basic standard protocols for implement equality checks.
1- The == and != operators.
2- The virtual Equals method.
The == and != are statically resolve, which means C# will make a compile-time decision as to which type will perform the comparison.
For instance the value-type
int x = 50;
int y = 50;
Console.WriteLine (x == y); // True
but for reference type
object x = 50;
object y = 50;
Console.WriteLine (x == y); // False
The Equals() originally resoled at runtime according to operand actual type.
For instance, in the following example, at runtime, it will be decided that the Equals() will apply on int values, the result is true.
object x = 5;
object y = 5;
Console.WriteLine (x.Equals (y)); // True
However, for a reference type, it will use a reference equality check.
MyObject x = new MyObject();
MyObject y = x;
Console.WriteLine (x.Equals (y)); // True
Note that Equals() uses structural comparison for struct, which means it calls Equals on each field of a struct.
Whether Equals() and == are the same depends on the implementation. Because C# allows users to set different behaviors for Equals() and == respectively.
class CompareTest
{
public readonly int val;
public CompareTest(int val)
{
this.val = val;
}
public override bool Equals(object obj)
{
return obj is CompareTest test && this.val == test.val;
}
public override int GetHashCode()
{
return val;
}
public static bool operator == (CompareTest a, object b)
{
return Equals(a, b);
}
public static bool operator != (CompareTest a, object b)
{
return !(a == b);
}
}
In this example, I made Equals() and == have the same behavior. But what if I make them different? For example:
public static bool operator == (CompareTest a, object b)
{
return false;
}
Equals() works normally but == will never works.
Furthermore, although I made them have the same behavior, but there is still one difference: which == function will be called depends on the left value:
Compare Test a = new CompareTest(1);
object b = new CompareTest(1);
CompareTest c = new CompareTest(1);
Debug.Log("AB " + (a == b)); // true
Debug.Log("BA " + (b == a)); // false! because it calls object's == function
Debug.Log("AC " + (a == c)); // true
Debug.Log("CA " + (c == a)); // true
When we create any object there are two parts to the object one is the content and the other is reference to that content.
== compares both content and reference;
equals() compares only content
http://www.codeproject.com/Articles/584128/What-is-the-difference-between-equalsequals-and-Eq
==
The == operator can be used to compare two variables of any kind, and it simply compares the bits.
int a = 3;
byte b = 3;
if (a == b) { // true }
Note : there are more zeroes on the left side of the int but we don't care about that here.
int a (00000011) == byte b (00000011)
Remember == operator cares only about the pattern of the bits in the variable.
Use == If two references (primitives) refers to the same object on the heap.
Rules are same whether the variable is a reference or primitive.
Foo a = new Foo();
Foo b = new Foo();
Foo c = a;
if (a == b) { // false }
if (a == c) { // true }
if (b == c) { // false }
a == c is true
a == b is false
the bit pattern are the same for a and c, so they are equal using ==.
Equal():
Use the equals() method to see if two different objects are equal.
Such as two different String objects that both represent the characters in "Jane"
The only difference between Equal and == is on object type comparison. in other cases, such as reference types and value types, they are almost the same(either both are bit-wise equality or both are reference equality).
object:
Equals: bit-wise equality
==: reference equality
string: (equals and == are the same for string, but if one of string changed to object, then comparison result will be different)
Equals: bit-wise equality
== : bit-wise equality
See here for more explanation.
I tried to followed the Guidelines from MSDN and also referred to This great question but the following seems to not behave as expected.
I'm trying to represent a structure similar to a FQN where as if P1 was listed before P2, P2 would only exist in the same set as P1. Like how scope works.
On the subject of GetHashCode()
I have a class with properties like this.
class data{
public readonly string p1, p2;
public data(string p1, string p2) {
this.p1 = p1;
this.p2 = p2;
}
public override int GetHashCode()
{
return this.p1.GetHashCode() ^ this.p2.GetHashCode();
}
/*also show the equal for comparison*/
public override bool Equals(System.Object obj)
{
if (obj == null)
return false;
data d = obj as data;
if ((System.Object)d == null)
return false;
/*I thought this would be smart*/
return d.ToString() == this.ToString();
}
public override string ToString() {
return "[" + p1 +"][" + p2+ "]";
}
}
In a Dictionary (dict) I use data as a key, so this would make the scope look like d1.p1.p2 (or rather p2 of p1 of d1, however you prefer to imagine it)
Dictionary<data,int> dict = new Dictionary<data,int>();
I've examined the behavior when d1.p1 and another d2.p1 are different, the operation resolves correctly. However when d1.p1 and d2.p1 are the same and p2 of d1 and d2 are different I observe the following behavior.
data d1 = new data(){ p1="p1", p2="p2" };
data d2 = new data(){ p1="p1", p2="XX" };
dict.add(d1, 0);
dict.add(d2, 1);
dict[d1] = 4;
The result is that both elements are 4
Is GetHashCode() overridden correctly?
Is Equals overridden correctly?
If they are both fine how/why does this behavior happen?
On the subject of a Dictionary
In the watch window (VS2013), I have my dictionary's key list show me, instead of a single key per index as I would normally expect, each property of my data object is a key for a single index. So I'm not sure if in there lay the problem or I'm just misunderstanding the Watch window's representation of an object as a key. I know how that is the way VS will display an object but, I'm not certain that's how I would expect it to be displayed for a key in a dictionary.
I thought GetHashCode() was a Dictionary's primary "comparison" operation, is this always correct?
What's the real "Index" to a Dictionary where the key is an object?
UPDATE
After looking at each hash code directly I noticed that they do repeat. Yet the Dictionary does not determine that the index exists. Below is an example of the data I see.
1132917379 string: [ABC][ABC]
-565659420 string: [ABC][123]
-1936108909 string: [123][123]
//second loop with next set of strings
1132917379 string: [xxx][xxx]
-565659420 string: [xxx][yyy]
//...etc
Is GetHachCode() overridden correctly?
Sure, for some definition of "correct". It may not be overridden well, but it's not an incorrect implementation (since two instances of the class that are considered equal will hash to the same value). Of course with that requirement you could always just return 0 from GetHashCode and it would be "correct". It certainly wouldn't be good.
That said your particular implementation is not as good as it could be. For example, in your class, the order of the strings matter. I.e. new data( "A", "B" ) != new data( "B", "A" ). However, these will always hash equal because your GetHashCode implementation is symmetric. Better to break the symmetry in some fashion. For example:
public int GetHashCode()
{
return p1.GetHashCode() ^ ( 13 * p2.GetHashCode() );
}
Now it's less likely that there will be a collision for two instances that are not equal.
Is Equal overridden correctly?
Well, it can definitely be improved. For example, the first null check is redundant and so is the cast to object in the second comparison. The whole thing would probably be better written as:
public bool Equals( object obj )
{
var other = obj as data;
if( other == null ) return false;
return p1 == obj.p1 && p2 == obj.p2;
}
I also removed the call to ToString since it doesn't significantly simplify the code or make it more readable. It's also an inefficient way of performing the comparison, since you have to construct two new strings before the comparison even happens. Just comparing the members directly gives you more opportunities for an early out and, more importantly, is a lot easier to read (the actual equality implementation doesn't depend on the string representation).
If they are both fine how/why does this behavior happen?
I don't know, because the code you've given won't do this. It also won't compile. Your data class has two readonly fields, you can't assign those using an initializer list as you've shown in your last code snippet.
I can only speculate as to the behavior you're seeing, because nothing you've shown here would result in the behavior as described.
The best advice I can give is to make sure that your key class is not mutable. Mutable types will not play nice with Dictionary. The Dictionary class does not expect the hash codes of objects to change, so if GetHashCode depends on any part of your class that is mutable, it's very possible for things to get very messed up.
I thought GetHachCode() was a Dictionary's primary "comparison" operation, is this always correct?
Dictionary only uses GetHashCode as a way to "address" objects (to be specific the hash code is used to identify which bucket an item should be placed in). It doesn't use it directly as a comparison necessarily. And if it does, it can only use it to determine that two objects are not equal, it can't use it to determine if they are equal.
What's the real "Index" to a Dictionary where the key is an object?
I'm not entirely sure what you're asking here, but I'm inclined to say that the answer is that it doesn't matter. Where the item goes is unimportant. If you care about that sort of thing, you probably shouldn't be using a Dictionary.
Is GetHashCode() overridden correctly?
No. You allow passing null for p1 or p2 and null.GetHashCode() throws a NullReferenceException which is not allowed in GetHashCode. Either forbid passing null, or make GetHashCode return an int for nulls (zero is OK).
You are also XORing unaltered ints; this means every class you create that contain two of the same values will have a hashCode of zero. This is a very common collision; typically one multiplies each hashcode by a prime number to avoid this.
Is Equals overridden correctly?
No. The page you linked to is the non-generic Equals used by System.Collections.HashTable. You are using the generic System.Collections.Generic.Dictionary, which uses the generic IEquatable<T>. You need to implement IEquatable<data> as explained in the accepted answer to the SO question you posted.
It is true that IEquatable<data> will fall back to Equals(System.Object obj) if not defined, but do not rely on that behavior. Also, converting ints to strings to compare them is not “smart”. Any time you feel you should write a comment excusing something as “smart” you are making a mistake.
A better implementation of 'data` would be:
public class MatPair : IEquatable<MatPair>
{
public readonly string MatNeedsToExplainWhatThisRepresents;
public readonly string MatNeedsToExplainThisToo;
public MatPair(string matNeedsToExplainWhatThisRepresents,
string matNeedsToExplainThisToo)
{
if (matNeedsToExplainWhatThisRepresents == null) throw new ArgumentNullException("matNeedsToExplainWhatThisRepresents");
if (matNeedsToExplainThisToo == null) throw new ArgumentNullException("matNeedsToExplainThisToo");
this.MatNeedsToExplainWhatThisRepresents = matNeedsToExplainWhatThisRepresents;
this.MatNeedsToExplainThisToo = matNeedsToExplainThisToo;
}
[Obsolete]
public override bool Equals(object obj)
{
return Equals(obj as MatPair);
}
public bool Equals(MatPair matPair)
{
return matPair != null
&& matPair.MatNeedsToExplainWhatThisRepresents == MatNeedsToExplainWhatThisRepresents
&& matPair.MatNeedsToExplainThisToo == MatNeedsToExplainThisToo;
}
public override int GetHashCode()
{
unchecked
{
return MatNeedsToExplainWhatThisRepresents.GetHashCode() * 31
^ MatNeedsToExplainThisToo.GetHashCode();
}
}
public override string ToString()
{
return "{" + MatNeedsToExplainWhatThisRepresents + ", "
+ MatNeedsToExplainThisToo + "}";
}
}
I have two objects in C# and don't know if it's Boolean or any other type.
However when I try to compare those C# fails to give the right answer.
I have tried the same code with VB.NET and that did it !
Can anyone tell me how to fix this if there is a solution ?
C#:
object a = true;
object b = true;
object c = false;
if (a == b) c = true;
MessageBox.Show(c.ToString()); //Outputs False !!
VB.NET:
Dim a As Object = True
Dim b As Object = True
Dim c As Object = False
If (a = b) Then c = True
MessageBox.Show(c.ToString()) '// Outputs True
In C#, the == operator (when applied to reference type expressions) performs a reference equality check unless it's overloaded. You're comparing two references which are the result of boxing conversions, so those are distinct references.
EDIT: With types which overload the ==, you can get different behaviour - but that's based on the compile-time type of the expressions. For example, string provides ==(string, string):
string x = new string("foo".ToCharArray());
string y = new string("foo".ToCharArray());
Console.WriteLine(x == y); // True
Console.WriteLine((object) x == (object) y); // False
Here the first comparison is using the overloaded operator, but the second is using the "default" reference comparison.
In VB, the = operator does a whole lot more work - it's not even just equivalent to using object.Equals(x, y), as things like Option Compare can affect how text is compared.
Fundamentally the operators don't work the same way and aren't intended to work the same way.
In addition to Jon’s answer which explains the C# side of things, here’s what VB does:
In VB with Option Strict On, a comparison via = always tests for value equality and never for reference equality. In fact, your code doesn’t even compile once you switch Option Strict On because System.Object doesn’t define an Operator=. You should always have this option on, it catches bugs more effectively than a venus flytrap (although in your particular case this lax behaviour actually does the right thing).1
In fact, with Option Strict On, VB behaves even stricter than C#: In C#, a == b either triggers a call to SomeType.operator==(a, b) or, if this doesn’t exist, invokes reference equality comparison (which is equivalent to calling object.ReferenceEquals(a, b)).
In VB on the other hand, the comparison a = b always invokes the equality operator.2 If you want to use reference equality comparison, you have to use a Is b (which is, once again, the same as Object.ReferenceEquals(a, b)).
1) Here’s a good indication why using Option Strict Off is a bad idea: I’ve used VB.NET for almost a decade, from before .NET’s official release until a few years ago, and I’ve absolutely no idea what a = b does with Option Strict Off. It does some kind of equality comparison, but what exactly happens and why, no idea. It’s more complex than C#’s dynamic feature, though (because that relies on a well-documented API). Here’s what the MSDN says:
Because Option Strict On provides strong typing, prevents unintended type conversions with data loss, disallows late binding, and improves performance, its use is strongly recommended.
2) Jon has mentioned one exception, strings, where equality comparison does some more things for reasons of backwards compatibility.
Object instances are not compared with the operator "==". You should to use method "equals". With "==" operator are comparing references, not objects.
Try this:
public class MyObject
{
public MyObject(String v)
{
Value = v;
}
public String Value { get; set; }
}
MyObject a = new MyObject("a");
MyObject b = new MyObject("a");
if(a==b){
Debug.WriteLine("a reference is equal to b reference");
}else{
Debug.WriteLine("a reference is not equal to b reference");
}
if (a.Equals(b)) {
Debug.WriteLine("a object is equal to b object");
} else {
Debug.WriteLine("a object is not equal to b object");
}
Results:
a reference is not equal to b reference
a object is not equal to b object
Now, try this:
public class MyObject
{
public MyObject(String v)
{
Value = v;
}
public String Value { get; set; }
public bool Equals(MyObject o)
{
return (Value.CompareTo(o.Value)==0);
}
}
MyObject a = new MyObject("a");
MyObject b = new MyObject("a");
if(a==b){
Debug.WriteLine("a reference is equal to b reference");
}else{
Debug.WriteLine("a reference is not equal to b reference");
}
if (a.Equals(b)) {
Debug.WriteLine("a object is equal to b object");
} else {
Debug.WriteLine("a object is not equal to b object");
}
Results:
a reference is not equal to b reference
a object is equal to b object
The issue is that the == operator in C# is a call to a static method (well, maybe not technically, but it can be though of as such) based on the compile time type of the two parameters. What the actual runtime types of those objects are doesn't matter.
Based on that compile time type the compiler will determine what implementation of operator == to use. It might use the default object implementation, it might use one of the numeric overloads provided by the language, or it could be a user defined implementation.
This is different from VB in that VB doesn't determine the implementation at compile time. It waits until runtime and inspects the two parameters that it is given to determine which implementation of the == operator it should use.
Your code contains boolean values, but they are in variables that are of type object. Because the variable is of type object, the C# compiler use the object implementation of ==, which compares the references, not the object instances. Since the boolean values are boxes, they don't have the same reference, even though their values are the same.
The VB code doesn't care what type the variable is. It waits until runtime and then checks the two variables, sees that they are actually of both of type boolean, and so uses the boolean == operator implementation. That implementation compares the values of the booleans, not their references (and the booleans will be unboxed before calling calling that operator, so a reference comparison doesn't even make sense any more). Because the values of the booleans are the same, it returns true.
I am relatively new to C#, and I noticed something interesting today that I guess I have never noticed or perhaps I am missing something. Here is an NUnit test to give an example:
object boolean1 = false;
object booloan2 = false;
Assert.That(boolean1 == booloan2);
This unit test fails, but this one passes:
object string1 = "string";
object string2 = "string";
Assert.That(string1 == string2);
I'm not that surprised in and of itself that the first one fails seeing as boolean1, and boolean2 are different references. But it is troubling to me that the first one fails, and the second one passes. I read (on MSDN somewhere) that some magic was done to the String class to facilitate this. I think my question really is why wasn't this behavior replicated in bool? As a note... if the boolean1 and 2 are declared as bool then there is no problem.
What is the reason for these differences or why it was implemented that way? Is there a situation where you would want to reference a bool object for anything except its value?
It's because the strings are in fact referring the same instance. Strings are interned, so that unique strings are reused. This means that in your code, the two string variables will refer to the same, interned string instance.
You can read some more about it here: Strings in .NET and C# (by Jon Skeet)
Update
Just for completeness; as Anthony points out string literals are interned, which can be showed with the following code:
object firstString = "string1";
object secondString = "string1";
Console.WriteLine(firstString == secondString); // prints True
int n = 1;
object firstString = "string" + n.ToString();
object secondString = "string" + n.ToString();
Console.WriteLine(firstString == secondString); // prints False
Operator Overloading.
The Boolean class does not have an overloaded == operator. The String class does.
As Fredrik said, you are doing a reference compare with the boolean comparison. The reason the string scenario works is because the == operator has been overloaded for strings to do a value compare. See the System.String page on MSDN.
As a kind of follow up to the question titled "Difference Between Equals and ==": in what kind of situations would you find yourself testing for reference equality in Java / C#?
Consolidating answers ...
When, typically, do you use ==
equality on a reference typed variable
in Java / C#?
1. To check for null:
if (a == null) ...
2. For efficiency when you are constructing an equals implementation:
boolean equals(Object o) {
if (o == null) return false;
if (this == o) return true;
// Some people would prefer "if (!(o instanceof ClassName)) ..."
if (getClass() != o.getClass()) return false;
// Otherwise, cast o, leverage super.equals() when possible, and
// compare each instance variable ...
3. For efficiency when you are comparing enums or comparing objects of a class designed such that comparing object identity is equivalent to checking object equivalence (e.g. Class objects):
enum Suit { DIAMONDS, HEARTS, CLUBS, SPADES }
class SomeCardGame {
...
boolean static isATrumpCard(Card c) {
return (c.getSuit() == TRUMP_SUIT);
}
}
4. When you really intend to check object identity, not object equivalence, e.g. a test case that wants to make sure a class isn't giving up a reference to an internal data structure instance.
boolean iChoseNotToUseJUnitForSomeReasonTestCase() {
final List<String> externalList = testObject.getCopyOfList();
final List<String> instanceVariableValue =
getInstanceVariableValueViaCleverReflectionTrickTo(testObject, "list");
if (instanceVariableValue == externalList) {
System.out.println("fail");
} else {
System.out.println("pass");
}
}
Interestingly, for point #3, one article suggests using equals is safer than using .equals() because the compiler will complain if you attempt to compare to object references that are not of the same class (http://schneide.wordpress.com/2008/09/22/or-equals/).
For Java, most commonly to see if a reference is null:
if (someReference == null) {
//do something
}
It is also pretty common with enums, but the most common place to use it that I've seen is in a properly implemented equals method. The first check will check for reference equality and only do the more expensive calculation if that returns false.
Because it's so fast and simple, == is routinely part of the Equals() function. If two objects are ==, then they're Equals, and you don't need any further processing. For primitives in Java, == is your only option (I don't think that's true of C#, but am not sure). I'll use == to test for null (although more frequently it's !=). Other than that... Stick with Equals(). It's rare and probably a sign of trouble to need == over Equals.
You can use it for quick equality checks.
For example if you are doing a compare with some very large objects that may take a while to iterate through, you can save time to see if they are referring to the same object first
Compare(LargeObj a, LargeObj b) {
if (a == b)
return true;
// do other comparisons here
}
In C#, the == operator may be overloaded, which would mean that you can compare reference types for LOGICAL equality.
Any time the implementer of a class thought that it would be logical to compare equality, you may do so using their methods.
This being said, be careful when checking if (a == b) in C#. This MAY be a reference equals, or it MAY be a logical comparison.
In order to keep the two cases distinct, it could be a good idea to use the two following methods, just to be clear:
object.ReferenceEquals(a, b)
a.Equals(b)
The first one is a reference comparison, and the second is usually a logical one.
here is a typical == overload, just for reference:
public static bool operator ==(RRWinRecord lhs, RRWinRecord rhs)
{
if (object.ReferenceEquals(lhs, rhs))
{
return true;
}
else if ((object)lhs == null || (object)rhs == null)
{
return false;
}
else
{
return lhs.Wins == rhs.Wins &&
lhs.Losses == rhs.Losses &&
lhs.Draws == rhs.Draws &&
lhs.OverallScore == rhs.OverallScore;
}
}
Try to avoid == with objects that are normally defined with final static and then passed as members in classes that are serialized.
For example (before we had enums) I had a class defined that simulated the idea of an enumeration. Since the constructor was private and all allowed instances were defined as final statics I wrongly assumed that == was always safe to use on these objects.
For example (typing code without compiling, so excuse me if there are some issues with the code)
public class CarType implements Serializable {
public final static CarType DODGE = new CarType("Dodge");
public final static CarType JEEP = new CarType("JEEP");
private final String mBrand;
private CarType( String pBrand ) {
mBrand = pBrand;
}
public boolean equals( Object pOther ) {
...
}
}
The CarType instances were serialized when used in other objects... but after materialisation (on a different JVM instance) the == operation failed.
Basically, you can use == when you "know" that "==" is equivalent to ".equals" (in Java).
By doing so, you can gain performance.
A simple example where you'll see this is in a .equals method.
public boolean equals(Object o) {
// early short circuit test
if (this == o) {
return true;
}
// rest of equals method...
}
But in some algorithms, you have good knowledge of the objects you're working with, so you can rely on == for tests. Such as in containers, working with graphs, etc.
My personal preference (C#) is to always leave == to mean reference equality (referring to the same object). If I need logical equivalence, I'll use Equals<T>. If I follow this rule uniformly, then there's never any confusion.