Kiedy użyłbyś List <KeyValuePair <T1, T2 >> zamiast Dictionary <T1, T2>?


96

Jaka jest różnica między listą KeyValuePair a słownikiem dla tych samych typów? Czy jest odpowiedni czas, aby użyć jednego lub drugiego?

Odpowiedzi:


81

Kiedy nie potrzebujesz szybkiego wyszukiwania klucza - utrzymanie tablicy hashy używanej przez Dictionaryma pewien narzut.


9
Również operacja wstawiania listy jest szybsza niż ta w Słowniku
Vadym Stetsiak

2
Jego pola są przeznaczone tylko do odczytu, ale zawsze możesz zastąpić cały element na liście.
Pavel Minaev

Więcej różnic tutaj
Vinni

63

Krótko mówiąc, lista nie wymusza unikalności klucza, więc jeśli potrzebujesz tej semantyki, to powinieneś użyć.


7
+1 Zauważ, że słownik również nie wymusza niepowtarzalności wartości!
gdoron wspiera Monikę

25

Słownik to typ ogólny, który zawiera kolekcję par klucz-wartość. Słownik jest szybki dla operacji wyszukiwania, ponieważ wewnętrznie używa funkcji skrótu . Oznacza to, że wszystkie klucze muszą być unikalne w słowniku .

Rozważ te przykłady:

List<KeyValuePair<int, string>> pairs = new List<KeyValuePair<int, string>>();
pairs.Add(new KeyValuePair<int, string>(1, "Miroslav"));
pairs.Add(new KeyValuePair<int, string>(2, "Naomi"));
pairs.Add(new KeyValuePair<int, string>(2, "Ingrid"));

Dictionary<int, string> dict = new Dictionary<int, string>();
dict.Add(1, "Miroslav");
dict.Add(2, "Naomi");
dict.Add(2, "Ingrid"); // System.ArgumentException: An item with the same key has already been added.

Dlatego zawsze powinieneś wziąć pod uwagę co najmniej dwie rzeczy:

  1. Chcesz przeszukać konkretne pozycje w słowniku?
  2. Czy chcesz, aby niektóre pola były nieunikalne (na przykład pary: imię / nazwisko).

1
Myślę, że chodzi o to, że klucze słownika muszą być unikalne, podczas gdy klucze List <KeyValuePair> nie mogą być unikalne.
Bruno Bieri

6
@BrunoBieri List <KeyValuePair> klucze mogą nie być unikalne
Nikhil Vartak

2
Poprawiłem Twój komentarz sprzed 2 lat i zauważyłeś to. Nic dziwnego, że SO jest jedyną zaufaną i najpopularniejszą platformą pytań i odpowiedzi.
Nikhil Vartak


7

Zgodnie z odpowiedzią Phillipa Ngana, SOAP lub innym, nie można serializować XML obiektów, które implementują IDictionary.

P: Dlaczego nie mogę serializować tabel skrótów?

Odp .: XmlSerializer nie może przetwarzać klas implementujących interfejs IDictionary. Wynikało to częściowo z ograniczeń harmonogramu, a częściowo z faktu, że obiekt hashy nie ma odpowiednika w systemie typu XSD. Jedynym rozwiązaniem jest zaimplementowanie niestandardowej tablicy haszującej, która nie implementuje interfejsu IDictionary.

stąd


5

W usługach sieciowych SOAP dla Silverlight odkryliśmy, że Dictionary nie są serializowane. Byłaby to sytuacja, w której użyłbyś listy KeyValuePair zamiast słownika.

.


3

Z http://blogs.msdn.com/bclteam/archive/2004/09/03/225473.aspx :

KeyValuePairkontra DictionaryEntry
[Krzysztof Cwalina]

Omówiliśmy problem z implementacją IEnumerableon Dictionary<K,V>. Jaki typ powinien IEnumerable.GetEnumerator().Current zwrócić? KeyValuePair<K,V>czy DictionaryEntry? To samo dotyczy ICollection.CopyTo. Wystąpienia jakiego typu należy skopiować do tablicy?

Zdecydowaliśmy, co następuje: IEnumerable i ICollectionimplementacje interfejsu będą używać KeyValuePair<K,V>jako typu elementu. IDictionaryokreśleni członkowie ( GetEnumeratorpowracający IDictionaryEnumerator) będą używać DictionaryEntryjako typu elementu.

Powodem jest to, że jesteśmy w trakcie wprowadzania zmian, które IEnumerator<T>mogłyby się rozszerzyć IEnumerator. Byłoby bardzo dziwne, gdybyśmy przechodząc po hierarchii od Dictionary<K,V>-> IEnumerable<T>-> IEnumerable nagle zmienili typ pozycji zwracanej z wyliczaczy.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.