Visual C # Developer Center: FAQs

Released on: 4/28/2004 | updated on: 4/28/2004

C # The Working Group and members of the C # community are answering frequently asked questions (FAQ) via web logs at http://blogs.msdn.com/csharpfaq. All entries in the site will be displayed to msdn through this page, and the cache will only cause a short delay.

Do you have any questions? Ask the workgroup a question through the contact option on the Network Log page.

Content on this page

	FAQ entries (by category)
	Latest entry
	When should I use =? When should I use equals?
	Should I assign null to a local variable?
	Why do I need to perform a null test before calling the delegate?

FAQ entries (by category)

•	Average
•	C # language and Compiler
•	Debugger/debugging
•	IDE
•	Equivalent entries of Visual Basic and C #

Back to Top

Latest entry

Why is the reference type not a polymorphism type?

Q: Why is the reference type not a polymorphism type?

A: Consider the following code:

using System;class Dog {   public string Name;}class Test{   public static void Swap(ref object a, ref object b) {      object temp;      temp = a;      a = b;      b = temp;   }   public static void Main() {      Dog d1 = new Dog();      d1.Name = "fido";      Dog d2 = new Dog();      d2.Name = "rex";      Swap(ref d1, ref d2);   }}

The compiler reports an error when calling the swap () function. Why? Consider the following form of the SWAp function:

public static void Swap(ref object a, ref object b) {      a = 5;      b = “Hello“;   }

If the compiler allows the above Code, this means that the boxed int type value is assigned to the dog object, which is obviously not type-safe.

[Author: Eric Gunnerson]

Release date:2004Year4Month8Day14:55:00 GMTThursdayComment(11)

Back to Top

When should I use =? When should I use equals?

The equals method is only a virtual method defined in system. object. It is overwritten by any class that chooses to execute the task. = Operator is an operator that can be overloaded by a class. This class usually has a constant behavior.

For reference types that are not overloaded with =, this operator compares whether two reference types reference the same object, which happens to be the work of The equals implementation in system. object.

For value types that are not overloaded with =, this operator checks whether the two values are "bitwise" equal, that is, whether each field in the two values is equal. This still happens when you call equals for the value type. However, this implementation is provided by valuetype and compared using reflection, this slows down the implementation of comparison speed bits based on types.

So far, the two are so similar. The main difference between the two is polymorphism. The operator is overloaded rather than overwritten, which means that the compiler only calls the constant version unless it knows the more specific version of the call. To clarify this, see the following example:

using System;public class Test{static void Main(){        // Create two equal but distinct strings        string a = new string(new char[] {'h', 'e', 'l', 'l', 'o'});        string b = new string(new char[] {'h', 'e', 'l', 'l', 'o'});        Console.WriteLine (a==b);        Console.WriteLine (a.Equals(b));        // Now let's see what happens with the same tests but        // with variables of type object        object c = a;        object d = b;        Console.WriteLine (c==d);        Console.WriteLine (c.Equals(d));    }}

The result is:

TrueTrueFalseTrue

The third line is false because the compiler does not know that the C and D content are both string references, so it can only call a non-overloaded version of =. Because they are references to different strings, the constant operator returns false.

So how should we use these operators differently? My principle is: for almost all reference types, use equals when you want to test equality instead of reference consistency. The exception is that string-use = to compare strings makes things much easier and the code is more readable,HoweverYou need to remember that both ends of this operator must be a type string expression to make the comparison normal.

For the value type, I usually use =, because unless the value type itself contains the reference type (which is rare in this case), it is irrelevant to whether the value type is constant or equal.

[Author: Jon Skeet]

Release date:2004Year3Month29Day15:56:00 GMTMondayComment(2)

Back to Top

Should I assign null to a local variable?

Q: Should I assign null to local variables after I use them?

For example:

string s = ...;Console.WriteLine(s);s = null;

A: in C #, you rarely need to perform this operation on local variables.

The lifetime of a variable is tracked by JIT. JIT analyzes the usage of the variable in the routine, accurately knows when the variable is no longer needed, and can be recycled later.

Interestingly, If you assign null to it, it actually slightly prolongs the lifetime of the variable, this may lead to a delay in garbage collection (although this is not a big difference ).

This is true for most methods. If you have a method, the code in this method will survive for a period of time (for example, executing a loop in an independent thread), you can check that while you are waiting, it may be meaningful to determine whether there are unnecessary values in the variable to survive.

[Author: Eric Gunnerson]

Release date:2004Year3Month26Day12:15:00 GMTFridayComment(5)

Back to Top

Why do I need to perform a null test before calling the delegate?

Q: Why do I need to perform a null test before calling the delegate?

A: If an event exists in the class, you need to add a null test before calling the delegate. Generally, you write the following code:

if (Click != null)    Click(arg1, arg2);

Here, there may actually be a race condition-the event may be cleared between the first row and the second row. You actually want to write the following code:

ClickHandler handler = Click;if (handler != null)    handler(arg1, arg2);

(Usually ). In other cases, you may need to synchronize data of another type.

Let's go back to the main issue. Why do we need to perform a null test?

We cannot change the existing behavior of a call by Delegate, because some applications may depend on it, so the language must be enhanced.

We have discussed how to simplify this problem by adding the invoke () keyword to the language. However, after in-depth discussions, we conclude that we cannot make mistakes at any time, so we decided to do nothing.

[Author: Eric Gunnerson]

Release date:2004Year3Month19Day12:41:00 GMTFridayComment(6)

Go to the original English page