C# Dictionary <> i zmienne klawisze

Question

Powiedziano mi, że jednym z wielu powodów, dla których napisy zostały uczynione niezmiennymi w specyfikacji C#, było uniknięcie wydania HashTables z kluczami zmienionymi, gdy odwołania do klawiszy string zmieniły ich zawartość.

Słownik <> typ umożliwia użycie typów odniesienia jako klucza. W jaki sposób słownik unika problemu zmienionych kluczy, które prowadzą do "niewłaściwie umieszczonych" wartości? Czy istnieje kliencki klon utworzony z obiektu, gdy jest używany jako klucz?

Answer 1

Typ Dictionary<TKey,TValue> nie podejmuje prób ochrony użytkownika przed modyfikacją użytego klucza. Tylko autor nie ponosi odpowiedzialności za mutację klucza.

Jeśli myślisz o tym trochę, to jest to jedyna rozsądna droga, którą może przyjąć Dictionary<TKey,TValue>. Rozważ implikację wykonania operacji podobnej do klonu członkowskiego na obiekcie. Aby być dokładnym, musisz wykonać głęboki klon, ponieważ będzie możliwe, że obiekt, do którego odnosi się ten klucz, również zostanie zmutowany i tym samym wpłynie na kod skrótu. Teraz każdy klucz użyty w tabeli ma swój pełny obiekt, klonowany w celu ochrony przed mutacją. Byłaby to zarówno błędna, jak i bardzo kosztowna operacja.

Answer 2

Klasa Dictionary<> nie chroni się przed zmianą zmieniającego się klucza. Od Ciebie zależy, czy klasa, której używasz jako klucza, jest zmienna, i jeśli to możliwe, unikaj jej.

Answer 3

Nie unika tej sytuacji. To do kodu wywołującego do egzekwowania tego:

Dopóki obiekt jest używany jako klucz w Dictionary<TKey, TValue>, musi nie zmienia w żaden sposób, który wpływa na jego wartość hash. Każdy klucz w Dictionary<TKey, TValue> musi być unikalny zgodnie ze słownikowym porównywarką równości. Klucz nie może być null, ale wartość może być, jeśli typ wartości TValue jest typem odniesienia.

(Od MSDN)

Answer 4

Jeśli używasz zmienny typ referencyjny jako klucz, wdrożenie domyślna GetHashCode() gwarantuje równość hash niezależnie od stanu obiektu (czyli hash jest związana z odniesienie, a nie stan). Masz jednak rację, że zmienny typ z semantyką równości wartości (gdzie GetHashCode prawdopodobnie zależy od stanu) jest złym wyborem dla klucza słownika.

Answer 5

Jeśli typ odniesienia nie zastępuje Equals/GetHashCode, słownik korzystający z domyślnego komparatora nie będzie dbał o żadne z pól lub właściwości kluczowych obiektów, a zatem nie zauważy lub nie będzie się przejmował, czy ulegną one zmianie. Najprościej jest pomyśleć o domyślnej metodzie GetHashCode zwracającej liczbę związaną z "identyfikatorem obiektu", a domyślną metodą Equals jako porównującą "id obiektu". Rzeczywiście, w systemie ograniczonym do dwóch miliardów lub mniej obiektów, GetHashCode może po prostu zwrócić identyfikator obiektu, ale z różnych powodów może również robić inne rzeczy.

Jeśli jedyną częścią obiektu zbadaną przez Equals lub GetHashCode jest identyfikator obiektu, to dla celów tych funkcji wszystkie obiekty są niezmienne. Gdy obiekt zostanie utworzony, zawsze będzie miał ten sam identyfikator i ten identyfikator nigdy nie będzie używany dla żadnego innego obiektu, dopóki wszystkie ślady dawnego identyfikatora obiektu nie znikną ze wszechświata.