[C#] collections*

Pagina: 1
Acties:
  • 446 views sinds 30-01-2008
  • Reageer

  • liquid_ice
  • Registratie: Februari 2001
  • Laatst online: 19-11 07:22
Ik ben nu met de nieuwe contest begonnen in C#. Alleen zit ik met een probleem omtrend m'n data opslag. De opslag moet dynamisch in formaat zijn.
De opslag hoeft niet gesorteerd te zijn, maar wel goed bereikbaar. Ik moet er namelijk VAAK door heen lopen en iets opzoeken, en dat moet processor vriendelijk gebeuren.

Nou ben ik verschillende dynamische typen tegen gekomen.

ArrayList
Collection
Dictionary
HashTable

Ik ben wezen zoeken naar de verschillen en wanneer ik welke het beste kan gebruiken, maar dat valt nog niet mee.

Zijn er nog meer van deze typen waar ik structs of classes in kwijt kan?
en in welke gevallen is het verstandig om welke type te gebruiken?

Klus page: http://klusthuis.blogspot.com


Verwijderd

Als 't niet om key/value pairs gaat, kies dan voor Collection (of ArrayList wanneer je nog met .NET 1.1 werkt, die ondersteunt nog geen generics).
En voor key/value pairs is Dictionary de opvolger van de HashTable.

  • liquid_ice
  • Registratie: Februari 2001
  • Laatst online: 19-11 07:22
ik wil de lijst vullen met structs. Elk struct staat voor een persoon.
Een persoon heeft een unieke naam en nog wat andere variabelen (zoals partner en voorkeur bijv.).
Hierbij is de naam dan de key en de andere de value, moet ik het zo zien?

Klus page: http://klusthuis.blogspot.com


  • Zr40
  • Registratie: Juli 2000
  • Niet online

Zr40

Moderator General Chat

heeft native IPv6

Verwijderd schreef op zondag 03 juni 2007 @ 07:16:
Als 't niet om key/value pairs gaat, kies dan voor Collection (of ArrayList wanneer je nog met .NET 1.1 werkt, die ondersteunt nog geen generics).
En voor key/value pairs is Dictionary de opvolger van de HashTable.
Collection? Bedoel je niet List<T>?

  • Zr40
  • Registratie: Juli 2000
  • Niet online

Zr40

Moderator General Chat

heeft native IPv6

liquid_ice schreef op zondag 03 juni 2007 @ 10:01:
ik wil de lijst vullen met structs. Elk struct staat voor een persoon.
Een persoon heeft een unieke naam en nog wat andere variabelen (zoals partner en voorkeur bijv.).
Hierbij is de naam dan de key en de andere de value, moet ik het zo zien?
Waarom structs? Een struct wordt, net als elke andere value type, gekopieerd als je hem meegeeft aan functies. Ik zou gewoon classes gebruiken.

  • liquid_ice
  • Registratie: Februari 2001
  • Laatst online: 19-11 07:22
oww, heb veel met C en C++ gewerkt.
met linked lists van structs ed.

Maar ik kan er wel classes van maken.
Maar dan blijft de vraag nog staan.

ik wil de lijst vullen met classes. Elke class staat voor een persoon.
Een persoon heeft een unieke naam en nog wat andere variabelen (zoals partner en voorkeur bijv.).
Hierbij is de naam dan de key en de anderen de value, moet ik het zo zien?

Klus page: http://klusthuis.blogspot.com


  • Zr40
  • Registratie: Juli 2000
  • Niet online

Zr40

Moderator General Chat

heeft native IPv6

De key is waarmee je je values opvraagt. Als je je person objecten wil opvragen aan de hand van de naam, gebruik je de naam als key en het person object als value.

  • liquid_ice
  • Registratie: Februari 2001
  • Laatst online: 19-11 07:22
moet de key in de value zitten?
of moet je een value en een losse key mee geven aan de Dictionary

Klus page: http://klusthuis.blogspot.com


  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 30-11 15:10

Creepy

Tactical Espionage Splatterer

Misschien handig dat je er gewoon eens mee aan de slag gaat? Het is niet dat er geen documentatie over een Hashtable of Dictionary te vinden is :)

De key hoeft niet "in" de value te zitten. De value kan in dit geval van alles zijn. De key wordt alleen maar gebruikt om het bijbehorende object op te halen.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


  • 4of9
  • Registratie: Maart 2000
  • Laatst online: 13-12-2024
Ik zou zelf een List<Persoon> gebruiken. En dan met behulp van predicates zoeken in de list. Of idd een key value pair.

[ Voor 12% gewijzigd door 4of9 op 03-06-2007 11:42 ]

Aspirant Got Pappa Lid | De toekomst is niet meer wat het geweest is...


  • liquid_ice
  • Registratie: Februari 2001
  • Laatst online: 19-11 07:22
@4of9, waarom zou je die gebruiken?

Klus page: http://klusthuis.blogspot.com


  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Omdat List<T> de standaard implementatie van een Lijst is in C#. Predicates zijn dan een handige manier om te zoeken. Zeker als je voor die Predicates annonymous delegates gebruikt is het heel intuitief vindt ik.

Als je altijd op naam wilt zoeken kun je het best een Dictionary<T> gebruiken. Dat scheelt je dan telkens je hele lijst doorzoeken.

Het antwoord over welke Collection je moet gebruiken is totaal afhankelijk van de manieren dat je elementen uit je lijst op wilt halen.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • liquid_ice
  • Registratie: Februari 2001
  • Laatst online: 19-11 07:22
Ik moet op 2 manieren elementen uit de lijst halen.
Als eerste heeft elk persoon een partner (en nog paar andere namen van maten en niet-maten).
Om dan die partner en de andere op te zoeken moet ik op naam zoeken.

MAAR ook moet ik door de lijst heen kunnen lopen, als een array oid

Klus page: http://klusthuis.blogspot.com


  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Dus je zoekt het meest op naam. Dan zou ik gebruik maken van een Dictionary<Persoon>. Een dictionary heeft ook een lijst met Values waar je nog door heen kunt lopen. Als je nog een bepaalde volgorde aan wilt houden kun je natuurlijk ook Zowel een List als een Dictionary kunnen gebruiken

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • DrDelete
  • Registratie: Oktober 2000
  • Laatst online: 20:46
Even MSDN erbij halen en je kunt dit vinden:

"Be sure to choose your System.Collections class carefully. Using the wrong type can restrict your use of the collection.

Consider the following questions:

Do you need a sequential list where the element is typically discarded after its value is retrieved?

If yes, consider using the Queue class or the Queue generic class if you need first-in-first-out (FIFO) behavior. Consider using the Stack class or the Stack generic class if you need last-in-first-out (LIFO) behavior.

If not, consider using the other collections.

Do you need to access the elements in a certain order, such as FIFO, LIFO, or random?

The Queue class and the Queue generic class offer FIFO access.

The Stack class and the Stack generic class offer LIFO access.

The LinkedList generic class allows sequential access either from the head to the tail or from the tail to the head.

The rest of the collections offer random access.

Do you need to access each element by index?

The ArrayList and StringCollection classes and the List generic class offer access to their elements by the zero-based index of the element.

The Hashtable, SortedList, ListDictionary, and StringDictionary classes, and the Dictionary and SortedDictionary generic classes offer access to their elements by the key of the element.

The NameObjectCollectionBase and NameValueCollection classes, and the KeyedCollection and SortedList generic classes offer access to their elements by either the zero-based index or the key of the element.

Will each element contain one value, a combination of one key and one value, or a combination of one key and multiple values?

One value: Use any of the collections based on the IList interface or the IList generic interface.

One key and one value: Use any of the collections based on the IDictionary interface or the IDictionary generic interface.

One value with embedded key: Use the KeyedCollection generic class.

One key and multiple values: Use the NameValueCollection class.

Do you need to sort the elements differently from how they were entered?

The Hashtable class sorts its elements by their hash codes.

The SortedList class and the SortedDictionary and SortedList generic classes sort their elements by the key, based on implementations of the IComparer interface and the IComparer generic interface.

ArrayList provides a Sort method that takes an IComparer implementation as a parameter. Its generic counterpart, the List generic class, provides a Sort method that takes an implementation of the IComparer generic interface as a parameter.

Do you need fast searches and retrieval of information?

ListDictionary is faster than Hashtable for small collections (10 items or fewer). The SortedDictionary generic class provides faster lookup than the Dictionary generic class.

Do you need collections that accept only strings?

StringCollection (based on IList) and StringDictionary (based on IDictionary) are in the System.Collections.Specialized namespace.

In addition, you can use any of the generic collection classes in the System.Collections.Generic namespace as strongly typed string collections by specifying the String class for their generic type arguments.
"

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:54
even de titel veranderd ....

https://fgheysels.github.io/


  • liquid_ice
  • Registratie: Februari 2001
  • Laatst online: 19-11 07:22
@DrDelete: zo'n uitleg was PRECIES wat ik zocht.

echt bedankt, ik had al gezocht op msdn, maar dit had ik niet gevonden...

Klus page: http://klusthuis.blogspot.com


  • whoami
  • Registratie: December 2000
  • Laatst online: 00:54
Tja, dan moest je ook ff gezocht hebben op 'collections', en niet op 'dynamic types'. :x

https://fgheysels.github.io/


  • liquid_ice
  • Registratie: Februari 2001
  • Laatst online: 19-11 07:22
thnx, zo leer ik nog wat :D

Klus page: http://klusthuis.blogspot.com


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
DrDelete schreef op maandag 04 juni 2007 @ 08:44:
Even MSDN erbij halen en je kunt dit vinden:
Als je de volgende keer ook nog even de bron URL vermeldt (http://msdn2.microsoft.co...rary/6tc79sx1(VS.80).aspx) is het ook nog eens prettiger-der-der leesbaar ;)

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


  • DrDelete
  • Registratie: Oktober 2000
  • Laatst online: 20:46
RobIII schreef op maandag 04 juni 2007 @ 10:44:
[...]

Als je de volgende keer ook nog even de bron URL vermeldt (http://msdn2.microsoft.co...rary/6tc79sx1(VS.80).aspx) is het ook nog eens prettiger-der-der leesbaar ;)
zit wat in, ik heb MSDN lokaal geinstalleerd staan ivm snelheid en beschikbaarheid, was ff te lui om online te kijken 8)

  • Mephix
  • Registratie: Augustus 2001
  • Laatst online: 25-11 20:41
Zr40 schreef op zondag 03 juni 2007 @ 10:23:
[...]

Collection? Bedoel je niet List<T>?
Zr40 schreef op zondag 03 juni 2007 @ 10:27:
[...]

Waarom structs? Een struct wordt, net als elke andere value type, gekopieerd als je hem meegeeft aan functies. Ik zou gewoon classes gebruiken.
Dit is eigenlijk de enige manier die ik nog gebruik... je business objects in classes definiëren en overal waar je een x aantal van dezelfde classes moet hebben, een List (Of <classname) gebruiken. Grote voordeel ten opzichte van een collection, is dat je niet hoeft te typecasten op de verschillende objecten in de collectie.

Je kunt dus Personen(0).Voornaam gebruiken, in plaats van CType(Personen(0), Persoon).Voornaam. Ook voor je intellisense is dit erg handig werken _/-\o_

Verwijderd

Collection<T> is net zo generic als List<T>, maar heeft wat minder overhead dan List. En ook wat minder mogelijkheden, maar da's geen ramp als je ze niet gebruikt.
't Kan zijn dat je in VB.NET bij Collection<T> moet typecasten, maar in C# is dat niet het geval.

  • titan_pi8
  • Registratie: Januari 2004
  • Laatst online: 11-11 23:10
Edit: nevermind vergissing...

[ Voor 96% gewijzigd door titan_pi8 op 05-06-2007 10:56 ]


Verwijderd

Verwijderd schreef op maandag 04 juni 2007 @ 22:00:
Collection<T> is net zo generic als List<T>, maar heeft wat minder overhead dan List. En ook wat minder mogelijkheden, maar da's geen ramp als je ze niet gebruikt.
Dit volg ik niet helemaal. Zoals ik het begrijp is ICollection enkel interface en zegt dat dus helemaal niets over eventuele 'overhead'. De implementatie zou dan immers dezelfde List kunnen . Tenzij er daadwerkelijk een concrete Collection class bestaat...

  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Verwijderd schreef op dinsdag 05 juni 2007 @ 11:04:
[...]
Dit volg ik niet helemaal. Zoals ik het begrijp is ICollection enkel interface en zegt dat dus helemaal niets over eventuele 'overhead'. De implementatie zou dan immers dezelfde List kunnen . Tenzij er daadwerkelijk een concrete Collection class bestaat...
Collection

[ Voor 72% gewijzigd door Woy op 05-06-2007 11:22 ]

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • whoami
  • Registratie: December 2000
  • Laatst online: 00:54
Er bestaat wel degelijk een List<T> en een Collection<T>
List<T> is basically a better ArrayList. It is optimized for speed, size, and power. Use it for majority of internal implementations whenever you need to store items in a container. Do not use it in public APIs.
Collection<T> is a much better CollectionBase. Use it to expose read/write collection output from public APIs. It’s in System.Collections.ObjectModel namespace. Why in a separate namespace and why such strange name? See here.
Collection<T> heeft een aantal methods die je kan overriden die uitgevoerd worden als een Item aan de collectie toegevoegd, verwijderd, etc... wordt. List<T> heeft die niet.
klik

[ Voor 19% gewijzigd door whoami op 05-06-2007 11:29 ]

https://fgheysels.github.io/


Verwijderd

Oh okee, ik vermoedde al zoiets maar mijn msdn search skills zijn alles behalve ontwikkeld. Wel een vrij onzinnige naam voor een concrete class overigens: het zegt namelijk compleet niets over het type collectie, doch wordt wel de interface IList geimplementeerd wat een geordende collectie impliceert.

  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Verwijderd schreef op dinsdag 05 juni 2007 @ 11:35:
[...]
Oh okee, ik vermoedde al zoiets maar mijn msdn search skills zijn alles behalve ontwikkeld. Wel een vrij onzinnige naam voor een concrete class overigens: het zegt namelijk compleet niets over het type collectie, doch wordt wel de interface IList geimplementeerd wat een geordende collectie impliceert.
Het is eigenlijk de opvolger van CollectionBase. Ik ben het er wel mee eens dat het een ietwat vreemde naam is aangezien IList geimplementeerd wordt.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • whoami
  • Registratie: December 2000
  • Laatst online: 00:54
Waarom impliceert een IList een geordende collectie ?

https://fgheysels.github.io/


Verwijderd

whoami schreef op dinsdag 05 juni 2007 @ 11:53:
Waarom impliceert een IList een geordende collectie ?
Waarom zou dat het niet doen? ;)
---
En natuurlijk omdat vandale dat ook vind
lijst (de ~, ~en)
1 opsomming van onder elkaar geplaatste namen van personen of zaken

[ Voor 29% gewijzigd door Verwijderd op 05-06-2007 11:58 ]


  • whoami
  • Registratie: December 2000
  • Laatst online: 00:54
Jij zegt dat het een 'geordende collectie' impliceert. Ik vraag je waarom je dat vind; ik vraag je niet om te antwoorden met een wedervraag.
IList impliceert geen geordende collectie; dat is nergens in de MSDN terug te vinden. Trouwens de 'SortedList' class -welke wel een geordende lijst representeert- implementeert IList niet eens.

https://fgheysels.github.io/


  • EfBe
  • Registratie: Januari 2000
  • Niet online
Een ongeorderde list van elements is nog altijd een list van elements, MET een orde, nl. GEEN orde.

Je mag niet veronderstellen dat IList de elementen in EEN bepaalde orde in zich heeft, want je moet dan ook kunnen bepalen welke orde. En die is niet gedefinieerd.

Exact eender in SELECT * FROM Table. De orde waarin de elementen worden teruggegeven is ongedefinieerd.

Ik moet het wel eens zijn met de stelling dat die interfaces maar een vergaarbak zijn in veel gevallen. Men was beter af geweest wanneer er een 'Set' concept was geintroduceerd ipv een collection en set operators vanaf het begin aanwezig waren geweest.

Maar het is niet allemaal kommer en kwel: een collection is een bak elementen, maar NIET per definitie een lijst. Een list is een collection EN een lijst, vandaar.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Verwijderd

whoami schreef op dinsdag 05 juni 2007 @ 11:59:
Jij zegt dat het een 'geordende collectie' impliceert. Ik vraag je waarom je dat vind; ik vraag je niet om te antwoorden met een wedervraag.
IList impliceert geen geordende collectie; dat is nergens in de MSDN terug te vinden. Trouwens de 'SortedList' class -welke wel een geordende lijst representeert- implementeert IList niet eens.
Toch was/is de wedervraag wel een interressante en een die gewoon nog beantwoord dient te worden. Het gaat er helemaal niet om wat er is gedocumenteerd in de msdn. Als we immers moeten terug vallen op de documentatie van een bepaalde bibliotheek dan hebben class namen geen enkele zin/toegevoegde waarde meer. Dat kan niet de bedoeling zijn. Een lijst is te alle tijde geordend: gedefinieerd of ongedefinieerd. Dat wil dus zeggen dat twee iteraties over de lijst twee maal dezelfde volgorde van elementen oplevert.


edit:
"gedefnieerd" en "ongedifnieerd" is onduidelijk, zeker met het verhaal van EfBe. Ik bedoelde te zeggen gedocumenteerd of ongedocumenteerd.

[ Voor 7% gewijzigd door Verwijderd op 05-06-2007 13:13 ]


  • liquid_ice
  • Registratie: Februari 2001
  • Laatst online: 19-11 07:22
WAAAAAAAA, vanaf de msdn link snap ik het niet meer...

Klus page: http://klusthuis.blogspot.com

Pagina: 1