Perché non esiste un'implementazione generica di OrderedDictionary in .net?

Perché Microsoft non ha fornito un'implementazione generica di OrderedDictionary?

Ci sono alcune implementazioni personalizzate che ho visto, tra cui: http://www.codeproject.com/KB/recipes/GenericOrderedDictionary.aspx

Ma perché Microsoft non l'ha incluso nella libreria .net di base? Sicuramente avevano un motivo per non costruire un generico .... ma che cos'è?

Prima di pubblicare questo messaggio, ho visto: /programming/2629027/no-generic-implementation-of-ordereddictionary

Ma questo conferma che non esiste. Non perché non esiste.

Grazie

c# .net

— nonot1
fonte

C'è sempre SortedDictionary<TKey, TValue>: msdn.microsoft.com/en-us/library/f7fta44c.aspx

— Travis Gockel

A meno che non fraintenda i documenti SortedDict, non è quello che voglio. Non voglio fare alcun ordinamento. Voglio solo un array a cui posso accedere anche con la chiave. Ad ogni modo, mi chiedo davvero perché MS abbia saltato questo. (Problemi

— discreti

Qual è un tipico caso d'uso per un dizionario ordinato? Sto lottando per pensare a uno fuori dalla cima della mia testa.

— Carson63000,

@Carson ogni volta che hai una serie di elementi di dati a cui hai anche bisogno di un rapido accesso casuale. Archiviare semplicemente in un Dict perde le informazioni di ordinazione e l'utilizzo di un array richiede il mantenimento del proprio indice.

— nonot1,

Chiedi a Eric Lippert di leggere e rispondere alla tua domanda. Di solito è molto gentile ad aiutare con questo tipo di domanda. Penso che puoi contattarlo tramite il suo blog: blogs.msdn.com/b/ericlippert

— devuxer,

Risposte:

In C # 4.0 In breve, ho letto questo:

An OrderedDictionaryè una combinazione di a HashTableeArrayList
Non esiste un generico ArrayList
"La ArrayListclasse non generica viene utilizzata principalmente per la retrocompatibilità con Framework 1.x ..."
"Un ArrayListè funzionalmente simile a List<object>"
"La riflessione è più facile con un non generico ArrayListdi un List<object>"

Conclusione?

Nessun generico OrderedDictionaryperché il costrutto sottostante è una classe (ufficiosamente) deprezzata che non ha una versione generica.

— radarbob
fonte

Questo non risponde davvero alla domanda. Ovviamente un OrderedDictionary generico potrebbe essere costruito su un Dizionario generico e su un Elenco generico.

— Jacques,

Un precetto dell'uso della classe è se l'interfaccia utente non cambia chi si preoccupa dell'implementazione? Bene, il team di progettazione / compilazione del linguaggio, diciamo, potrebbe preferire il generico ereditando la sua controparte non generica . Il mio senso spidey vacilla. Per i principianti: i diversi antenati (immediati) sono una miniera di terra da qualche parte nel percorso evolutivo della OrderedDictionarycovarianza e della varianza?

— radarbob,

Il OrderedDictionarysovraccarico dell'operazione di indicizzazione in modo che l'indicizzazione con un numero intero Nmantenga l'elemento in posizione N, mentre l'indicizzazione con un Objectrecupererà l'elemento corrispondente a quell'oggetto. Se uno dovesse creare un OrderedDictionary<int, string>chiamato myDicte aggiungere elementi (1, "George") e (0, "Fred") in quell'ordine, dovrebbe myDict[0]restituire "George" o "Fred"?

Tale problema avrebbe potuto essere risolto imponendo un vincolo di classe sul tipo di chiave. D'altra parte, gran parte dell'utilità delle raccolte generiche deriva dalla loro capacità di lavorare in modo efficiente con tipi di valore. Imporre un vincolo di classe al tipo di chiave sembrerebbe un po 'brutto.

Se la classe non dovesse essere conforme a CLS ma dovesse semplicemente funzionare con vb.net, un design ragionevole avrebbe potuto essere usato con proprietà indicizzate. Quindi, nell'esempio sopra, myDict.ByKey[0]avrebbe ceduto "Fred" e myDict.BySequence[0]avrebbe ceduto "George". Sfortunatamente, lingue come C # non supportano le proprietà indicizzate denominate. Mentre uno avrebbe potuto comprendere qualcosa per consentire l'uso della sintassi di cui sopra anche senza tali proprietà, la sfortunata decisione di avvolgere i campi di strutture come Pointe Rectanglesignifica che per myDict.ByKey[0] = "Wally"funzionare, myDict.ByKeydovrebbe restituire un nuovo oggetto di classe. Una struttura sarebbe più efficiente, ma i compilatori rifiuterebbero ciò che sembrava una scrittura in una struttura di sola lettura (nonostante la proprietà non modificherebbe la struttura restituita daByKey, ma modifica invece la raccolta a cui contiene un riferimento).

Personalmente, penso che un oggetto dizionario-dizionario che è stato specificato come tenere traccia dell'ordine di inserimento sarebbe una cosa carina da avere; Mi piacerebbe anche avere un oggetto dizionario-ish che potrebbe facilmente restituire la chiave associata a una chiave particolare (in modo che, ad esempio se uno ha un dizionario senza distinzione tra maiuscole e minuscole e ha aggiunto un record con una chiave di "GEORGE", uno potrebbe chiedere al dizionario quale chiave è associata a "George" senza dover cercare tra tutti gli KeyValuePairoggetti restituiti in un elenco.

— Supercat
fonte

Perché il mantenimento dell'ordine impedisce la ricerca O (1) implicita da IDictionary a meno che non si impacchettino due raccolte (una per l'ordine, una per la ricerca), il che rende l'aggiunta / rimozione meno performante e aumenta l'utilizzo della memoria. Oppure potresti avere una ricerca più lenta in cambio di un minore utilizzo della memoria.

La mia ipotesi è che non ci fosse scelta 'chiaramente migliore' qui, quindi non è andato nella libreria standard. Soprattutto intorno al 2.0, C # stava ancora imparando dagli errori di Java. Non sarei sorpreso se l'approccio di Java "tutto e il lavandino della cucina" alle raccolte nella loro libreria standard fosse visto anche come qualcosa da evitare.

— Telastyn
fonte

Avere una ricerca più lenta in cambio di meno memoria rende efficacemente OrderedDictionarya List. Immagino che chiunque abbia un caso d'uso legittimo per un lo OrderedDictionarysta usando specificamente perché hanno bisogno di una classe di raccolta che ha una ricerca O (1) ma ricorda anche l'ordine di inserimento, nel qual caso l'uso di memoria aggiuntiva è inevitabile e quindi accettabile.

— Abion47,