Compare String and Object in C#

Compare String and Object in C#

In each case, the second operand of == is x, which is of type object. That means you're using the normal reference equality operator.

Now in your first case, you're using two string constants with the same contents. The C# compiler will use a single object for those two references. In the second case, x and y refer to distinct string objects with the same contents. The two references will be different, so == will return false.

You can fix the comparison by:

• Use Equals instead - that's overridden by string (as opposed to the == operator which is only overloaded:

  Console.WriteLine(y.Equals(x)); // or x.Equals(y), or Equals(y, x)
  

  The use of the static Equals(object, object) method can be useful if either of the arguments can be null; it means you don't need to worry about a NullReferenceException.

• Make both variables of type string, at which point the == overload within string will be picked at compile-time, and that overload compares the contents of the strings, not just the references

It's worth noting that it's not just a matter of the string literals itself being noticed by the C# compiler - it's about compile-time constant expressions. So for example:

object x = "mehdi emrani";
string y = "mehdi " + "emrani";
Console.WriteLine(y == x); // True

Here y is initialized using two string literals which aren't the same as the one used to initialize x, but the string concatenation is performed by the compiler, which realizes it's the same string it's already used for x.

Comparing C# object

A quick and dirty check of memory addressing helps to shine light on this using this (grabbed from here):

public static IntPtr GetAddress(object o)
{
    unsafe
    {
        TypedReference tr = __makeref(o);
        IntPtr ptr = **(IntPtr**)(&tr);
        return ptr;
    }
}

You can then do this:

Console.WriteLine(GetAddress(str1));
Console.WriteLine(GetAddress(str2)); 
Console.WriteLine(GetAddress(int1)); 
Console.WriteLine(GetAddress(int2));

I get:

35839968
35839968
35840128
35840152

What you should see is that the address of str1 and str2 are identical, and the address of int1 and int2 are different. This is because your strings are interned (because they are string literals). A single copy of the string shahrooz is stored in memory and both str1 and str2 are referring to it. Your int1 and int2 on the other hand are being boxed which is taking the value type int and placing it inside an object. Each int (or any other value type) boxed gets put in its own box with its own address.

Now the default behavior of == when given two reference types (like object) is to just compare the memory address (to see if they refer to the same object), and this is what's happening. In the case of the strings, it's the same object. In the case of the ints, it isn't.

As others have suggested, using Equals will give the desired result because Object.Equals is virtual and can be overridden, hence calling the appropriate int.Equals when given int and string.Equals when given a string.

Comparing two objects with == operator

I am not sure why it changes when you change it from 10 to 1

I believe this is an implementation detail and you should not rely on it (will try to find something in the specs) but some positive single digit numbers are cached in int.ToString implementation for .NET Core. Here is excerpt from UInt32ToDecStr which is called internally by int.ToString:

// For single-digit values that are very common, especially 0 and 1, just return cached strings.
if (bufferLength == 1)
{
    return s_singleDigitStringCache[value];
}

As for equality - please check:

1. C# difference between == and Equals().
2. String interning in .Net Framework. (compiler will intern string literals, so all of them will point to the same address in memory)
3. Using type dynamic

UPD:

Was not able to find anything in specs, but next code behaves differently in .NET Framework and .NET 6 (former one prints 11 times False and the latter prints 10 times True and one False):

var dict = new Dictionary<int, string>()
{
    {0, "0"},
    {1, "1"},
    {2, "2"},
    {3, "3"},
    {4, "4"},
    {5, "5"},
    {6, "6"},
    {7, "7"},
    {8, "8"},
    {9, "9"},
    {10, "10"},
};

foreach(var kvp in dict)
{
    Console.WriteLine(object.ReferenceEquals(kvp.Key.ToString(), kvp.Value));
}

UPD2:

The caching was introduced for performance reasons by this PR and is mentioned in Performance Improvements in .NET Core 3.0 blogpost:

In some sizeable web applications, we found that a large number of strings on the managed heap were simple integral values like “0” and “1”. And since the fastest code is code you don’t need to execute at all, why bother allocating and formatting these small numbers over and over when we can instead just cache and reuse the results (effectively our own string interning pool)? That’s what PR dotnet/coreclr#18383 does, creating a small, specialized cache of the strings for “0” through “9”, and any time we now find ourselves formatting a single-digit integer primitive, we instead just grab the relevant string from this cache.

private int _digit = 4;

[Benchmark]
public string SingleDigitToString() => _digit.ToString();

object o = "mymy";
string s = "my";
Console.WriteLine(o == s+s);

aa.Equals(bb)

string.Equals(aa,bb)

a == b

public static bool operator ==(string a, string b)
{
    return string.Equals(a, b);
}