tags:

views:

183

answers:

3

Try the following in the Immediate window:

object a1 = "a";
object a2 = "a";
a1==a2 // outputs false

and you'll see that a1 == a2 outputs false.

However, at runtime in either a window app or console, you'll get true:

object t1 = "a";
object t2 = "a";
MessageBox.Show((t1 == t2).ToString()); // outputs true

The runtime behavior is consistent with the definition for the == operator and strings.

Does anybody know if this a bug in the Immediate window?

+13  A: 

What you are describing is correct behaviour.

The definition of == in Object compares the references of its arguments. This is different from the implementation of == for String which compares the values of the strings. Operators in C# are not virtual. This means that even though your objects are actually strings, because the static type is object the == from Object is called, meaning a reference comparison will be made.

In C# strings can be interned in the intern pool. Normally when you create new strings at runtime you receive a reference to a completely new string object. To get an interned string you can call the string.Intern method. However when you compile C# code, the literal strings are interned automatically for you so if you have the same literal string in two places in your code you will get a reference to the same string object.

In the immediate window the strings are apparently not interned - new strings are created each time even if they have the same value. But there is no requirement in .NET that all strings must be interned, so I do not consider this to be a bug.

Your code should avoid relying on whether or not strings are interned as this is an implementation detail.

Mark Byers
Just to make things clear for the OP : operators don't participate in polymorphism, so in that case it's the `Object` implementation of `==` that is used, not the `String` implementation, hence this unexpected behavior.
Thomas Levesque
I don't agree with the "correct bahavior" statement.The Immediate window behavior is not consistent with the MSDN documentation and with the run-time, nor even with itself when you put a break point and actually test variables that are present in the code. I personally think Microsoft should fix this.
Damiano
@Damiano: What do you mean by: "The Immediate window behavior is not consistent .. with itself when you put a break point and actually test variables that are present in the code."? Can you give an example? "The Immediate window behavior is not consistent with the MSDN documentation" What specific part of the documentation are you referring to?
Mark Byers
+2  A: 

This is not a bug; the reason that your runtime code works is because those strings are interned (that is, there is only one representation of those particular character sequences in memory. Every reference to the constant "a" refers to the same point in memory). In the immediate window, a new string is created for each one, so while their content is the same, the objects point to different locations in memory.

Using the == operator on a reference type performs a reference comparison (unless the specific type as the object is being referenced, not what the object is--meaning object in this case, not string--alters this behavior). Because the compiled literal strings are interned, they have the same reference. Because the immediate window strings are new strings, they do not have the same reference.

Adam Robinson
+2  A: 

Probably at runtime the compiler will optimize the string literals to point to the same reference location, but in the immediate window this optimization doesn't occur.

SztupY