1

I have the Following Code 

 CASE 1 string string1 = "pankaj"; string string2 = "pankaj"; Console.WriteLine(string1 == string2); // output TRUE CASE 2 object obj1 = "pankaj"; object obj2 = "pankaj"; Console.WriteLine(obj1==obj2); // Output TRUE CASE 3 object againObject1 = 2; object againObject2 = 2; Console.WriteLine(againObject1==againObject2); // Output FALSE

as string and object are both reference type and for reference type I learned that equality operation checks if they hold the same address, in above two case why its comparing value instead of references.

what is more confusing is the behavior of equality operator for object type in case 2 and case 3 for string type it computes true and for integers its return false.

Improve this question
4
  • Because of compiler optimazations there is only one string created 'Pankaj'. In case of integers there are two diffrent objects will be created. Go through the following link stackoverflow.com/questions/4286614/… Commented Dec 3, 2014 at 11:01
  • I think it is because string literals are interned, so there is only ever one instance of "pankaj". Console.WriteLine(object.ReferenceEquals(obj1,obj2)); will return true for case 2 as well. Commented Dec 3, 2014 at 11:01
  • possible duplicate of Trying to understand == operator with objects Commented Dec 3, 2014 at 11:01
  • 1
    Also explained here: stackoverflow.com/questions/3470145/… Commented Dec 3, 2014 at 11:02

4 Answers 4

Reset to default
5

String equality is different. Among many other things...

Example 1 and 2 will in both cases return the exact same object - the INTERNED string ("pankaj" exists only once after internalization, and all constant strings are internalized).

Example 3 has 2 boxed objects without any optimization - so 2 boxes around a value type.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

After decompilation in IL the two string are differents
The difference come from that the Int is a struct that don't overrride the == operator whereas the string class does
Actually no, in this particular case it even comes from all strings being the SAME OBJECT due to internalization of static strings during compilation/class loading. The string override does only come into account when you dynamically create strings.
@Ludovic - I believe TomTom is correct. While the == operator is indeed overloaded, it is overloaded to call string.Equals. The first check that string.Equals does is to check if ((Object)a==(Object)b) Only if that check fails, does it then go on to compare the values of the strings.
@Ludovic please read stackoverflow.com/questions/6568905/… - the CLR does not care what you see in IL. All string literals are internalized. So, for the test to have any meaning the strings must be constructed, not literals.
0

Strings are objects and integers also are, but the later are type values. So the example 3 is pointing to two different places in memory and you are trying to compare their addresses by boxing them on objects.

Improve this answer

Comments

-1

using: object1==object2 isn't comparing the content of the object, instead it's a comparison of the storage-address, if the object is comparable use object1.equals(object2)

Improve this answer

Comments

-1

The String class has overridden operator == so as to implement comparison by value, and the Int32 class has not.

Improve this answer

2 Comments

Nothing to do with this, case 2 is comparing 2 objects so according to your explanation obj1==obj2 would be false.
Everything to do with this.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.