10.5. The == operator

The == operator in C# deserves some attention from Java developers. It works in exactly the same way the == operator works in Java except for one case – when the operands are string objects.

The == operator behaves differently depending on what its operands are:

• when used to check the equality of two value types, ^[8] the operator returns true if both operands have the same value – this is the same for Java;

  ^[8] Simple types (such as int, long, char, etc.) are value types.

• when used to check the equality of two reference types, the operator returns true only if the types refer to the same object in memory – this is the same for Java too.

The program below demonstrates these points.

 1: using System;
 2:
 3: class TestClass {
 4:
 5:   public static void Main(){
 6:     int i=5;
 7:     int j=5;
 8:     // comparison of value types
 9:     Console.WriteLine(i==j); // true
10:
11:     object o1 = (object)i;
12:     object o2 = (object)j;
13:     object o3 = o2;
14:     // comparison of reference types
15:     Console.WriteLine(o1==o2); // false
16:     Console.WriteLine(o2==o3); // true
17:   }
18: }

Output:

c:expt>test
True
False
True

Both o2 and o3 refer to the same object on the heap, and that's the reason why the expression (o2==o3) is true. Even though all the fields of the objects referenced by o1 and o2 have the same values, (o1==o2) is false because they refer to distinct objects on the heap.

10.5.1. Comparing string objects

So far, the use and behavior of the == operator has been the same in C# as in Java. The significant difference between the == operator in C# and Java arises when it is used to compare string objects. In this case, the values of the two strings are compared instead of whether they refer to the same string object on the heap, despite the fact that a string is a reference type, not a value type. The program below demonstrates this.

 1: using System;
 2:
 3: class TestClass {
 4:
 5:   public static void Main(){
 6:     string s1 = "apple";
 7:     string s2 = "apple";
 8:     Console.WriteLine(s1==s2); // true
 9:     s1 = "orange";
10:     Console.WriteLine(s1==s2); // false
11:     s1 = "apple";
12:     Console.WriteLine(s1==s2); // true
13:   }
14: }

Output:

True
False
True

In this program, two unique string objects are created on lines 6 and 7. The == operator returns true if the string literals encapsulated by the string objects which are used as the operands are the same.

Here is a short note to dispel some confusion for Java developers experimenting with Java Strings. Unlike C#, strings objects are not singled out as exceptional cases when compared using the == operator. When used to compare string objects, the == operator in Java returns true if the string variables used as the operands refer to the same string object, and false if two unique string objects are being compared, even if they both encapsulate the same string literal. Examine the Java program below.

1: // Test.java
2: public class Test{
3:   public static void main(String args[]){
4:     String a = "apple";
5:     String b = "apple";
6:     System.out.println(a==b); // true
7:   }
8: }

Output:

true

The output from the Java program above does not seem to follow this rule. The reason for this strange output is because the statements on lines 4 and 5 actually produced only one string object, rather than two separate string objects each encapsulating identical string literals. String declarations made like this in Java result in only one string object being created. (a==b) returns true because a and b are both referring to the same string object on the heap.

To prove this, change line 5 a little to force a new String object to be created:

5:     String b = new String("apple");

This time, the output will show false. The statement above actually forces a new string object referenced by b to be created. In this case, object reference variables a and b refer to separate string objects both encapsulating the same string literal. A comparison with the == operator hence returns false as expected.