[C#] Dictionary met 1 TKey/Multi-type Tvalue

[Suicyder]

Hallo tweakers,

ik heb sinds een aantal dagen C# opgepakt als programmeertaal om mijzelf aan te leren. Ik ben bekend met meerdere talen vanuit het verleden (het is echter nogal verroest geraakt).

Echter wil ik het mezelf niet te makkelijk maken en heb ik een projectje opgezet voor mezelf waarbij ik nu tegen een iets aan loop.

Ik ben voor dit project op zoek naar de mogelijkheden voor het volgende.
Ik zou graag een mogelijkheid vinden voor een Dictionary met 1 TKey en meerdere verschillende typen TValue's.
Dus:

code:

Dictionary inhoud -> String (key), int, string, int, int (values)

Nou zag ik wel de mogelijkheid voor het volgende, maar weet ik niet of ik dan simpele berekeningen kan maken met de integer values welke ik hierin kwijt zou willen:

code:

Dictionary<string, List<object>

Een database is niet echt een optie omdat het grote stroom informatie oplevert welke uiteindelijk elke seconde ververst zou moeten worden (of iets langzamer) en ik vrees dat een database hiervoor te langzaam zou worden met het wegschrijven & uitlezen.

Bij voorbaat dank,

[Russel88]

Is int, string, int, int vast gedefinieerd?
Zoja, dan kun je toch een klasse maken met 3 int en 1 string propertie?

Dan heb je een Dictionary van <string, JouwObject>

[Suicyder]

Int, string, int, int is vast inderdaad. Ik ga je suggestie eens bekijken, had ik nog niet bedacht zo.

[HMS]

Of iets als een Tuple?

MSDN: Tuple Class (System)

[Suicyder]

Okey, om even een update te geven, ik had de dictionary werkend met een object met int/string/int/int. Echter bedacht ik me net op het moment dat ik dat had gedaan dat dit niet nodig was en ik het gewoon af kan met een simpele

code:

Dictionary<string, List<int>>

Stom, maar ik heb wel geleerd hoe ik het moet doen mocht het ooit nodig zijn!!

ps. ik heb niet echt een plan/methode voor deze tool, zo klooi ik het meeste met verschillende mogelijkheden en leer ik meer

[Marcj]

Zelfs als je af kan met alleen maar een verzameling van integers, dan nog zou ik daar een apart object voor maken. Zoals je het uitlegt klinkt het alsof elk van de 4 integers een aparte betekenis heeft. Door deze in een object te gooien maak je deze betekenis expliciet (bijvoorbeeld door de naamgeving), wat het gebruik ervan makkelijker maakt.

Een List<int> als value gebruik je alleen als je verschillende reeksen van getallen verwacht, waarbij de getallen zelf geen vaste betekenis hebben.

Een andere mogelijk oplossing is het maken van 4 Dictionary objecten met elk een verwijzing naar een van de waardes. Dit kan conceptueel kloppen wanneer de waardes eigenlijk niets met elkaar te maken hebben, maar toevallig wel aan dezelfde keys hangen.

[Russel88]

Dictionary<string, List<int>> zou ik gebruiken als je niet weet hoe groot je lijst zal worden.
In jouw geval weet je dat en dan is een object mooier.
[code=c#]

dic["Jan"].Leeftijd == dic["Kees"].Leeftijd
[/code=c#]
leest makkelijker dan
[code=c#]
dic["Jan"].[2] == dic["Kees"].[2]
[/code=c#]

[Verwijderd]

Marcj schreef op dinsdag 16 april 2013 @ 16:15:
Een andere mogelijk oplossing is het maken van 4 Dictionary objecten met elk een verwijzing naar een van de waardes. Dit kan conceptueel kloppen wanneer de waardes eigenlijk niets met elkaar te maken hebben, maar toevallig wel aan dezelfde keys hangen.

Dat is geen geschikte oplossing voor TS. Hij heeft 1 key en meerdere waarden, niet andersom. Het aanmaken van meerdere maps betekent dat je ook meer dan een lookup nodig hebt om alle waarden op te halen. Bij een enkele map kan je af met 1 lookup.

Als je het nog sneller wilt, gebruik dan een hash table.

[Marcj]

Verwijderd schreef op dinsdag 16 april 2013 @ 16:19:
[...]

Dat is geen geschikte oplossing voor TS. Hij heeft 1 key en meerdere waarden, niet andersom. Het aanmaken van meerdere maps betekent dat je ook meer dan een lookup nodig hebt om alle waarden op te halen. Bij een enkele map kan je af met 1 lookup.

Als je het nog sneller wilt, gebruik dan een hash table.

Ik lees nergens dat hij alle waardes perse met 1 lookup wil hebben. Wanneer de verschillende type waardes niet op hetzelfde moment nodig zijn is het conceptueel verdedigbaar om meerder Dictionary (of HashTable) objecten te gebruiken.

Ik ben met je eens dat deze oplossing waarschijnlijk langzamer is, maar ik probeer even de opties te schetsen

Als de waardes wel op hetzelfde moment nodig zijn, is er waarschijnlijk een duidelijke relatie en zouden de waardes in een Object horen. Dit maakt het een stuk leesbaarder, zoals het voorbeeld van Russel88 ook duidelijk maakt.

Verder vind ik het gebruik van Tuples in een OO-taal echt niet kunnen. Dat zijn dan een soort 'poor-mans' objecten zonder duidelijke naamgeving.

ps. Is een Dictionary onder water niet ook gewoon een hash tabel? Ik zit meer in Java, dus ik weet het niet zeker.

[ Voor 4% gewijzigd door Marcj op 16-04-2013 16:26 ]

[Verwijderd]

Ik maakte snel de vertaalslag van dictionary naar C++ map. Ik weet zo niet wat een dictionary 'onder water' is. Misschien is het inderdaad al een hash table.

Ik zie zo snel geen 'less' parameter, wel een IEqualityComparer<T>. Dat houd dus in dat het al een hash table is.

[Phyxion]

Er zit wel wat verschil tussen hoor:

Dictionary <<<>>> Hashtable differences:

Generic <<<>>> Non-Generic
Needs own thread synchronization <<<>>> Offers thread safe version through Synchronized() method
Enumerated item: KeyValuePair <<<>>> Enumerated item: DictionaryEntry
Newer (> .NET 2.0) <<<>>> Older (since .NET 1.0)
is in System.Collections.Generic <<<>>> is in System.Collections
Request to non-existing key throws exception <<<>>> Request to non-existing key returns null
potentially a bit faster for value types <<<>>> bit slower (needs boxing/unboxing) for value types

Dictionary / Hashtable similarities:

Both are internally hashtables == fast access to many-item data according to key
Both need immutable and unique keys
Keys of both need own GetHashCode() method


Is het aantal int's altijd dezelfde size?

[R4gnax]

Phyxion schreef op dinsdag 16 april 2013 @ 16:41:
Er zit wel wat verschil tussen hoor:

Dictionary <<<>>> Hashtable differences:

Needs own thread synchronization <<<>>> Offers thread safe version through Synchronized() method

Je hoeft dat anders helemaal niet zelf te programmeren hoor.