C # types are derived from System.Object
Ancestor's fine Tradition: The public method of object
Equals: Identity rather than equality of objects
GetHashCode: The hash code that returns the value of the object
ToString: The full name of the default return type this. GetType (). FullName
GetType: Returns an instance of an object derived from type, that is, the object's metadata information, which is a non-virtual method, to prevent the class from overriding the method, concealing the actual type information, thereby destroying the type of security
What's the use of GetHashCode?
A quick check that determines whether an object is equal. The override of the Equals method and the GetHashCode method should exist at the same time. If the result returned by the Equals method is true, the GetHashCode method should return the same result. If the GetHashCode method returns the same result, the result of the Equals method is not necessarily true.
 
public class Student {public string FirstName {get; private set;} public string LastName {get; private set;} Public Student (String firstName, String lastName) {this. FirstName = FirstName; This. LastName = LastName; } public override bool Equals (object obj) {Console.WriteLine ("called Equals"); if (obj = = NULL | | this. GetType ()! = obj. GetType ()) return false; return this. FirstName = = ((Student) obj). FirstName && this. LastName = = ((Student) obj). LastName; } public override int GetHashCode () {Console.WriteLine ("called GetHashCode"); return this. Firstname.gethashcode (); }} static void Main (string[] args) {Student student1 = new Student ("June", "Lei"); Student Student2 = new Student ("Kaifu", "Li"); Student Student3 = new Student ("June", "Zhu"); First call var dic = new dictionary<student, object> (); DIC[STUDENT1] = new Object (); Console.WriteLine ("=================="); Console.WriteLine (DIC. ContainsKey (Student2)); Console.WriteLine ("=================="); Console.WriteLine (DIC. ContainsKey (STUDENT3)); The second call Student student4 = new Student ("June", "Lei"); var dic1 = new dictionary<student, object> (); DIC1[STUDENT4] = new Object (); Console.WriteLine ("=================="); Console.WriteLine (Dic1. ContainsKey (New Student ("June", "Lei")); }
Note: In the above student class, we rewrite the Equals and GetHashCode methods of the two base classes, in order to determine the value of dictionary hash value of the key values of the system by default call GetHashCode judgment, And then to use the Equals method to judge, Microsoft agreed that if the hash code of two objects is different, then two objects must be unequal. Therefore, the system defaults to calling this method to make the simplest judgment when judging the object equality. For example: To compare two people is not a brother, the first eye must be to see whether the gender of two people is the same (GetHashCode), if the gender is not the same, certainly not brothers, and then judge the appearance, blood type, DNA and other similarities (Equals).
The first time the above code is called, the output is as follows:
In student we rewrite the GetHashCode method to get the hash value of the FirstName, which means that if the two student FirstName the same, the default hash value returned by the system will be the same when the two objects are equal. We can see that each field in the Student1 and Student2 objects is not the same, so the eradication of GetHashCode direct judgment is not equal, so the system returns false directly, not the Equals method to judge. The Student3 object and the Student1 object's FirstName is the same, so the sense hash value has not been judged out, so called once the Equals method for in-depth judgment, because the LastName is not the same, so the return result is false. From the above code we can conclude that the system to determine the equality of objects when the first call GetHashCode judgment, if the object's hash value, and then according to the implementation of the equals to judge, otherwise directly return false.
If we comment out the implementation of the GetHashCode, and use the system method directly, the result is as follows:
Because Student1 and Student3 are two different objects, the hash code must not be the same, so the Equals method is not invoked to continue the judgment.
Primitive type
Primitive type: The data type directly supported by the compiler is called a primitive type, and it maps directly to a type that exists in the Framework class library (FCL), such as Int-> System.Int32
int a = 0; The most convenient syntax for system.int32 a = 0; Convenient syntax int a = new int ();//Inconvenient Syntax System.Int32 a = new System.Int32 (); The most inconvenient syntax
Question 1: is the IL code generated by the above four lines of code exactly the same? (exactly the same, can be judged based on the generated IL code)
Issue 2: when running on a 32-bit operating system, int represents a 32-bit integer, and when running on a 64-bit operating system, int represents a 64-bit integer is this the correct statement? (full error, no matter what operating system represents a 32-bit integer)
The following is the correspondence between primitive types in C # and types in the FCL
Reference type:
A. Memory allocation on the managed heap
B. Each object allocated on the managed heap will contain: The value of the object itself, the type object pointer, the synchronization index block
C. The object is passed the reference address of the memory
D. When not in use, it will be garbage collected
Eg: classes are reference types, string
Value type:
A. Memory allocation to where it is declared
B. The allocated memory contains only its own value
C. The value itself is passed
D. not be garbage collected
E. All value types are implicitly closed sealed (prevents one value type from being used as a base type for other types)
F. All value types are descendants of System.ValueType
Eg:int, decimal, double, struct
About the type object pointer of the reference type and the synchronized index block, the following blog will be very detailed, but I still do not fully understand, all do not do a detailed explanation here.
Type object pointer and synchronous index block: http://www.cnblogs.com/yuyijq/archive/2009/03/13/1410071.html
Code1:
String str = "AB"; string str1 = Str;str = "abc"; str1 =?
The above code you must think that STR1 will output ABC, because it is a reference type Ah, we changed the value of the reference after it will follow this side, because the reference is the same memory address AH. If I really think so, I can only say that I'm too young.
The output is still AB for the following reasons:
the immutability of string : The String object is read-only and once the object is created, the value of the object cannot be modified. It seems to have changed, the actual string has been specially processed, each time the value is changed to create a new string object, the variable will point to the new object, and the original is still pointing to the original object, so it will not change. This is also why string is inefficient, and if you change the value of string frequently, you should use StringBuilder instead of string
Stringbulider: To resolve these problems by assigning a cache (workspace), apply the StringBuilder class's method to the string in the workspace. Includes add, delete, remove, insert and replace characters, and more. After execution, the ToString method is called to convert the contents of the workspace to a string that is convenient for assigning to a string variable. This StringBuilder will improve some performance.
Code2:
string str1 = "string"; string str2 = "string"; Console. WriteLine (String. ReferenceEquals (STR1, str2));
Although we initialized two string objects and seemed to be allocating two memory addresses, it was not, and the CLR optimized it for the following reasons:
When the CLR initializes, an internal hash table is created, key is a string, and value is a reference to a string object in the managed heap. When constructing a str1, the hash list is first queried for the existence of a "string" string, if it does not exist, a new string object is constructed in the managed heap, and a "string" string and a reference to the object are added to the hash table, when the str2 is constructed, because the hash table exists Key is a reference to "string" and assigns value to STR2, then str1 and str2 refer to the same string object
Note: string is a type of immutable reference, the CLR is optimized at run time, and the same string actually exists in memory for only one copy
CODE3:
Public struct , point {public int x = 0; public int y = 0; }
The code above is not compiled, because:
A value type does not support parameterless constructors, and it is not possible to initialize a field in the definition if it does not provide any of the parameter constructors.
Why does Microsoft not support parameterless constructors for value types?
Prevents developers from explicitly calling constructors, and for variables of value types, if the constructor is not explicitly called, the compiler does not add code that calls the constructor in the generated IL code.
C # Type Basics (top)