The C # Working Group and members of the C # community are answering the FAQ (FAQ) through the web log (blog), the URL is: http://blogs.msdn.com/csharpfaq. All entries in this site will be displayed in the MSDN through this page, and the middle is only short-lived due to the cache.
Do you have any questions? Please ask questions to the working group through the contact options in the Network Log page.
This page
FAQ entry (arrangement by category) When is the latest entries you should use ==? When should I use Equals? Should I assign NULL to a local variable? Why do you need a NULL test before calling the delegate?
FAQ entry (arrangement by category)
• General • C # language and compiler • Debugger / debugging • IDE • Visual Basic and C # equivalent
Back to top
Latest entry
Why is the reference type not a polymorphic type?
Q: Why is the reference type not a polymorphic type?
A: Please 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 SWAP function using the following form:
Public Static Void Swap (Ref Object A, REF Object B) {
A = 5;
B = "Hello";
}
If the compiler allows you to use the above code, this will mean to assure the packaged int type value to the DOG object, which is obviously not type safe.
[Author: Eric Gunnerson]
Published: April 8, 2004 14:55:00 GMT Thursday Reviews (11)
Back to top
When should I use ==? When should I use Equals?
The equals method is just a virtual method defined in System.Object, which is rewritten by any class that selects the task. == The operator is an operator that can be overloaded by class, which usually has constant behavior.
For reference types that are not overloaded ==, the operator compares whether the two reference types are referenced to the same object, and this is exactly the work made by the Equals implementation in System.Object.
For value types that are not overloaded ==, the operator compares whether these two values are "bit" equal, that is, whether each of these two values is equal. This situation will still happen when you call Equals to the value type, but this time, this implementation is provided by valueetype and compares to the reflection, so that the comparison speed is much slower than the type.
So far, the two are so similar. The main difference between the two is polymorphism. The operator is overloaded instead of being rewritten, which means that it is only called constant version unless the compiler knows the more specific version. To clarify this, please see below: use 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));
}
}
turn out:
True
True
False
True
The third line is False because the compiler does not know that the contents of C and D are string references, so it can only call == non-overloaded versions. Because they are references to different strings, the constant operator returns false.
So, how should I use these operators? My criterion is: For almost all reference types, use Equals when you want to test equality rather than reference consistency. The case is a string - use == Comparison string does make more simple things, and the code readability is better, but you need to remember that both ends of the operator must be type string expressions, The comparative is normal.
For value type, I usually use ==, because unrecorded type itself contains reference types (this is extremely rare), it is constant to equal or equal problems.
[Author: Jon Skeet]
Published: March 29, 2004 15:56:00 GMT Monday Comments (2)
Back to top
Should I assign NULL to a local variable?
Q: Will NULL will be assigned to them after I use a local variable?
E.g:
String s = ...;
Console.WriteLine (s);
s = NULL;
A: In C #, there is little need to perform this operation on the local variable.
Variables The life of the variable is determined by JIT trace. The JIT will analyze the usage mode in the routine to accurately understand when this variable is no longer needed, and knows that this value will be recycled later.
Interestingly, if you assign NULL to it, it is actually slightly extending the survival period of the variable, which may result in the time to drag it for garbage collection (although this is actually a little likely to have a real difference).
This is true for most ways. If you have a method, the code in this method survives for a while (for example, executing a loop in the stand-alone thread), check if there is no need to survive in the variable in the process of waiting, it may be meaningful. . [Author: Eric Gunnerson]
Published: March 26, 2004 12:15:00 GMT Friday Comments (5)
Back to top
Why do you need a NULL test before calling the delegate?
Q: Why do you need a NULL test before calling a delegate?
A: If there is an event in the class, you need to add NULL test before calling the delegate. Often, you write the following code:
IF (Click! = NULL)
Click (arg1, arg2);
It may actually have a contention condition - events may be cleared between the first row and the second line. You actually want to write the following code:
ClickHandler Handler = Click;
IF (Handler! = NULL)
Handler (arg1, arg2);
(usually). Under other occasions, you may need to make some kind of synchronization.
Let us return to the main problem. Why do I need a NULL test?
We cannot change the existing behavior of the call by delegate, because some applications may rely on it, so they must be enhanced.
We have discussed that this problem has become simpler by adding invoke () keywords to the language, but after in-depth discussion, we conclude that we can't make mistakes at all times, so we decided nothing. .
