Basic knowledge: The hashtable and list containers add the same object of the attribute.

At noon today, I talked about my question at the Beijing blog Park club:

 Question, Basic Knowledge: A custom Type T1, a set list, list. after add (T1), change the attribute name value of T1 and then list. add (T1 ). are the two values in the list equal? In this case, is the list a value or two values?

My head immediately gave an answer:

1. Equal, 2. Two values

Not to mention whether the answer is correct, extract the following content:

Zi Qiu said:
Question, Basic Knowledge: A custom Type T1, a set list, list. after add (T1), change the attribute name value of T1 and then list. add (T1 ). are the two values in the list equal?
Zi Qiu said:
In this case, the list is a value or two values.

Fan Shi (Assembly head) said:

1. Equal, 2. Two values

Zi Qiu said:
The head is really good.

Chen Hongwei said:
It depends on whether you have added it twice or once.
..... [Several thousand-character chat records are omitted later]

I moved a small bench and watched the brothers argue about the issue. At this time, I am not very sure that the answer is correct, because I did not pay too much attention to the internal implementation of the list, so I did not dare to talk about it. Although I have studied the source code of hashmap in Java some time ago, I dare not determine whether it must be equal or not equal. Later, the head brother gave the program written with vb10 as follows:

Dim A = new with {. Name = "Harry "}
Dim L = {A}. tolist ()
A. Name = "Potter"
L. Add ()

......

At that time, I didn't have a. NET development environment, so I didn't have any comments. Later, I pulled it to hashtable. Finally, I got the conclusion that "the two values are equivalent. They are all modified T1 attributes." The Chat has come to an end.

Anyone who has no theoretical basis or has no practical experience can conclude that they are not responsible for others. In view of this, after returning, I simply looked at the internal implementation of list and hashtable, and found that the logic of its internal container and its add method are quite different.

1. List

The internal container of list <t> is an array of type T, as shown below:

Private T [] _ items;

 

The add method is as follows:

Public void add (T item ){
If (_ size = _ items. Length) ensurecapacity (_ SIZE + 1 );
_ Items [_ SIZE ++] = item;
_ Version ++;
}

From this point of view, no matter whether the field value of the object you add has changed, its internal array is unconditionally stored in the object t you add, all maintenance points to the same reference of the object. At the same time, the returned value is actually the number of times you call the add method, that is, the internal _ size field:

Public int count {
Get {return _ size ;}
}

 

Therefore, it is not difficult to answer why the answer to the question in the beginning of autumn is "two values, equal.

2. hashtable

During the chat, I raised the following question: "What will happen if an object that overwrites the hashcode and equals methods as a key is put into hashtable ?" This problem was raised due to an inexplicable problem on the production machine some time ago, it took me nearly a day to find the schema in the persistent layer framework written by the company's predecessors, which was caused by incorrect rewriting of equals. At that time, I almost vomited blood.

The answer to my questions is as follows:If the hashcode of an object changes, it is not suitable for storing it in hashtable.

First, let's look at the internal container of hashtable, which is actually a struct, as follows:

Code
// The hash table data.
// This cannot be serialised
Private struct bucket {
Public object key;
Public object val;
Public int hash_coll; // store hash code; sign bit means there was a collision.
}

 

Has_coll is used to maintain the hashcode Of the key. when calling the add method, it first checks whether the hashcode element of the key already exists in the array buckets of the struct type Bucket, if no such item exists, the key and value are put into the struct array at the same time. If yes, an "added item" exception is thrown, that is, the item of the repeat value cannot be added.

If the hashcode and equals methods are rewritten as follows:

Code
Class Customer
{
Public string name {Get; set ;}

Public override int gethashcode ()
{
Return name. gethashcode ();
}

Public override bool equals (Object OBJ)
{
Return (customer) OBJ). Name = This. Name;
}
}

Then, after changing the object name to a value, add it to hashtable as a key without throwing an exception.

According to the previous hashtable internal container struct, it is easy to see, hashtable checks whether an object already exists, that is, whether the hashcode of the key already exists in the struct array maintained internally, if the hashcode and equals methods are rewritten according to the method I mentioned above, the hashcode values obtained when the name attribute of the object changes are different, in this case, objects placed in hashtable are not considered to be an existing object, but objects placed in hashtable before changing the value cannot be indexed through keys, that is, it is lost (but if you change the name value of the object back to the original value, you can find it again ......)

Objects whose hashcode may be changed are not suitable for storing in hashtable.

I often look at the basics, which is actually very helpful for us to improve.

 

If there is anything wrong with the above, please correct it.

More friends are welcome to join the Beijing blog Park Club.