[C# / .NET] Geen "std::set" in System.Collections ?

[MrBucket]

Ben ik nou gek, of zit er in de System.Collections-namespace helemaal geen datatype voor gebalanceerde binaire bomen (zoals een AVL-tree of een red-black tree)? Zit ik misschien in de verkeerde namespace te kijken?

Ik zoek een datastructuur die z'n elementen gesorteerd opslaat in een binary tree, en die in logaritmische tijd kan zoeken. Zoals de std::set die in de STL van C++ zit.

Heb ik m'n ogen echt in m'n broekzakken zitten, of bestaat zoiets standaard niet in .NET?

[Woy]

Volgens mij bestaat zoiets standaard niet in .net. Er zullen vast wel library's te downloaden zijn die dit wel aanbieden.

Anders is het ook niet al te moeilijk om zelf een AVL tree te implementeren.

[MSalters]

De std::set uit STL.NET gebruiken?

[Woy]

Ik heb even snel gegoogled naar stl.net en zover ik zag bestaat die pas vanaf .net 2.0

[MrBucket]

Wat gebruiken jullie zelf dan voor'n library (of evt. vervangende datastructuur)?

Ik kan me niet voorstellen dat niemand die bezig is met .NET behoefte heeft aan een set of een map.

[alienfruit]

Geen idee, maar een binary tree maken lijkt mij toch niet zo moeilijk in C#? Of is dit allemaal wat anders? Ik heb geen benul van std::set. Anders is ArrayList niet goed ?

[ Voor 11% gewijzigd door alienfruit op 21-07-2005 02:39 ]

[curry684]

Ondanks dat de documentatie er niets over zegt verwacht ik persoonlijk wel dat DictionaryBase aan een vorm van balancing doet intern. Wat voor extreem geval heb je overigens te pakken dat het echt uit zou maken dat ie per definitie volledig balanced is?

[SlowMeDown]

Ondanks dat de documentatie er niets over zegt verwacht ik persoonlijk wel dat DictionaryBase aan een vorm van balancing doet intern.

Dan moet ik jou teleurstelllen. DictionaryBase gebruikt intern gewoon een Hashtable als opslag.

De Hashtable gebruikt intern een array van buckets. In iedere bucket wordt dan de key, value en een hash opgeslagen. Daar is helemaal niks gebalanceerds aan. De hash (via InitHash) wordt als index voor de bucket array gebruikt.

[EfBe]

SlowMeDown schreef op donderdag 21 juli 2005 @ 08:59:De Hashtable gebruikt intern een array van buckets. In iedere bucket wordt dan de key, value en een hash opgeslagen. Daar is helemaal niks gebalanceerds aan. De hash (via InitHash) wordt als index voor de bucket array gebruikt.

... die dus sneller is dan een balanced tree. (vooral inserts)

Er is veel discussie geweest, waarom er geen linked list e.d. in .NET zit, maar zoals hierboven al werd geroepen, die kun je zo zelf maken, dus daar is niet echt een standard class voor nodig. Het gaat er nl. niet om HOE de informatie is opgeslagen, maar dat je het er snel uitkrijgt. Behalve mensen met teveel tijd en verkeerde prioriteiten zullen er weinig developers zijn die per se een balanced tree opslag willen gebruiken voor hun data, ookal hebben ze een store die sneller is.

[alienfruit]

Mischien heb je wat aan PowerCollection van één ontwikkelaars van de C# compiler, het bevat namelijk een redblacktree unit testcase. Je kan natuurlijk ook gewoon een ArrayList gebruiken, het is vaak een betere en efficiëntere oplossing dan een linked list.

http://www.wintellect.com...code/PowerCollections.zip

[ Voor 25% gewijzigd door alienfruit op 21-07-2005 09:17 ]

[.oisyn]

EfBe schreef op donderdag 21 juli 2005 @ 09:13:
[...]

... die dus sneller is dan een balanced tree. (vooral inserts)

Het probleem is dat een hashtable geen order bijhoudt, een tree wel. En dát is het grote verschil tussen het gebruik van een hashtable en een set of map

[farlane]

EfBe schreef op donderdag 21 juli 2005 @ 09:13:
Behalve mensen met teveel tijd en verkeerde prioriteiten zullen er weinig developers zijn die per se een balanced tree opslag willen gebruiken voor hun data, ookal hebben ze een store die sneller is.

Of mensen die iets willen hebben dat balanced is en waarbij snelheid van minder belang om een of andere reden waar jij nog niet aan gedacht hebt?

[EfBe]

.oisyn schreef op donderdag 21 juli 2005 @ 11:26:
[...]
Het probleem is dat een hashtable geen order bijhoudt, een tree wel. En dát is het grote verschil tussen het gebruik van een hashtable en een set of map

Mwah, het is maar hoe je een 'set' defineert natuurlijk. In theorie is die niet georderd, als ik me niet vergis.

farlane schreef op donderdag 21 juli 2005 @ 11:51:
[...]


Of mensen die iets willen hebben dat balanced is en waarbij snelheid van minder belang om een of andere reden waar jij nog niet aan gedacht hebt?

Ok, maar dan maak je die toch zelf? Het werk van het maken van een balanced tree is nl. de IComparer, niet de structuur.

Het punt is dat bij een hashtable er veel werk zit in het bouwen van het hashgedeelte, wat een framework class dus jou uit handen neemt. Een balanced tree IMHO is qua framework class erg dun en werkt niet zonder een comparer en niet zonder het feit dat het object dat je in een node stopt comparable is.

De topicstarter kwam op mij over alsof hij een structuur zocht waar hij elementen in kon opslaan en die in non-lineaire tijd er weer uit kon krijgen, nou dat is de hashtable. (of de hybride variant in Collections.Specialized) Als je een balanced tree wilt, dan zit die er niet in nee, net als een single linked list, double linked list, circular linked list en andere datastructure die ooit zijn verzonnen.

[ Voor 63% gewijzigd door EfBe op 21-07-2005 12:35 ]

[.oisyn]

EfBe schreef op donderdag 21 juli 2005 @ 12:28:
[...]

Mwah, het is maar hoe je een 'set' defineert natuurlijk. In theorie is die niet georderd, als ik me niet vergis.

Een ordered set dan, je snapt best wat ik bedoel. Het punt is hier de ordering, niet welk naampje je eraan hangt. MrBucket vroeg om een std::set, die is wel georderd. Het is dé datastructuur als je snel wilt zoeken naar elementen en ordening wilt behouden, of het opzoeken van hele ranges (in O(log N) tijd). .Net biedt die functionaliteit idd niet, en dat vind ik nogal raar (zat algoritmes die ik ken hebben een dergelijke datastructuur nodig).

Het punt is dat bij een hashtable er veel werk zit in het bouwen van het hashgedeelte, wat een framework class dus jou uit handen neemt. Een balanced tree IMHO is qua framework class erg dun en werkt niet zonder een comparer en niet zonder het feit dat het object dat je in een node stopt comparable is.

Ik zou een implementatie van een red-black algoritme anders niet trivialer willen noemen dan een hash-probing algoritme

[ Voor 7% gewijzigd door .oisyn op 21-07-2005 12:49 ]

[alienfruit]

RedBack.cs Een eitje om over te zetten naar versie 1.0.

/// The Red-Black tree manages items of type T, and uses a IComparer<T> that
/// compares items to sort the tree. Multiple items can compare equal and be stored
/// in the tree. Insert, Delete, and Find operations are provided in their full generality;
/// all operations allow dealing with either the first or last of items that compare equal.

[ Voor 105% gewijzigd door alienfruit op 21-07-2005 13:13 . Reden: voor boelste keer editen :) Tikken is moeilijk ]

[MrBucket]

EfBe schreef op donderdag 21 juli 2005 @ 09:13:
Het gaat er nl. niet om HOE de informatie is opgeslagen, maar dat je het er snel uitkrijgt. Behalve mensen met teveel tijd en verkeerde prioriteiten zullen er weinig developers zijn die per se een balanced tree opslag willen gebruiken voor hun data, ookal hebben ze een store die sneller is.

Hier ben ik het niet mee eens. Als er voor c# net zo'n uitgebreide library aan datastructuren beschikbaar zou zijn als voor Java of C++, dan zou je wel gek zijn om een ArrayList te gebruiken - natuurlijk neem je dan de datastructuur die het best geschikt is voor de job.
Ik had eerlijk gezegd niet verwacht om genoodzaakt te zijn third-party libraries hiervoor te gebruiken.

Wat betreft die PowerCollections, bedankt! Lijkt me een goed beginpunt

[.oisyn]

alienfruit schreef op donderdag 21 juli 2005 @ 12:53:
RedBack.cs Een eitje om over te zetten naar versie 1.0.

[...]

Beetje jammer, zijn er ook niet functies die comparen op kleiner dan of groter dan, ipv alleen equal? Want dat is nou juist zo handig aan trees

C++ kent dan ook de lower_bound() en upper_bound() functies voor de set en map varianten. lower_bound() retourneert het eerste element waarvoor geldt element >= key en upper_bound doet een element > key. Op die manier kun je dus 2 iterators krijgen binnen een bepaalde range.

[riezebosch]

De vraag is: heb je het in .NET überhaupt nodig? Als je voor snelheid of geheugen gaat, kies je toch niet voor C#. Daarom denk ik dat de ArrayList eigenlijk altijd voldoet.

edit:

Hoewel ik voor m'n project wel zelf ook een Tree geschreven heb

[ Voor 20% gewijzigd door riezebosch op 21-07-2005 15:13 ]

[.oisyn]

Dat is natuurlijk een nonargument. Dat het op een VM draait wil natuurlijk niet meteen zeggen dat je maar genoeg hoeft te nemen met het langzaamste van het langzaamste. Waarom bestaat er anders überhaupt een hashtable?

[MrBucket]

riezebosch schreef op donderdag 21 juli 2005 @ 15:12:
De vraag is: heb je het in .NET überhaupt nodig? Als je voor snelheid of geheugen gaat, kies je toch niet voor C#. Daarom denk ik dat de ArrayList eigenlijk altijd voldoet.

edit:

Hoewel ik voor m'n project wel zelf ook een Tree geschreven heb

Lijkt me niet. Stel dat ik werk met gesorteerde data. Als ik in C++ / Assembly gebruik maak van een ArrayList, en in C# een set, dan weet ik bijna zeker dat mijn C#-applicatie sneller zal zijn voor een collectie van 100 of meer elementen.

Bovendien, een datastructuur die zijn data ten alle tijde gesorteerd heeft werkt gewoon veel eleganter als een ArrayList waarbij je eerst een binary search en vervolgens een lineaire-tijd insert moet doen. Of, nog erger, na elke Add() opnieuw sorteren.

[alienfruit]

Beetje jammer, zijn er ook niet functies die comparen op kleiner dan of groter dan, ipv alleen equal? Want dat is nou juist zo handig aan trees

C++ kent dan ook de lower_bound() en upper_bound() functies voor de set en map varianten. lower_bound() retourneert het eerste element waarvoor geldt element >= key en upper_bound doet een element > key. Op die manier kun je dus 2 iterators krijgen binnen een bepaalde range.

offtopic:
In de tijd dat we deze discussie hebben gehad, had de TS allang zijn gesorteerde treebouw geval ding in C# kunnen hebben

[ Voor 15% gewijzigd door alienfruit op 21-07-2005 17:01 ]

[EfBe]

riezebosch schreef op donderdag 21 juli 2005 @ 15:12:
De vraag is: heb je het in .NET überhaupt nodig? Als je voor snelheid of geheugen gaat, kies je toch niet voor C#. Daarom denk ik dat de ArrayList eigenlijk altijd voldoet.

Stop maar eens 1000 elements in een arraylist en ga dan maar es zoeken. Linear search! (indexOf, contains... allemaal lopen ze alle elements af en roepen Equals aan)

---------------
Kijk ik snap best dat mensen allerlei structuren willen in het framework, maar men gaat aan het punt voorbij dat wanneer je GEEN generics hebt (en dat is het geval bij .NET 1.x) je middels externe objects je structuur moet bouwen, dus middels een comparer en IComparable implementaties op de values. Dat maakt een 'framework' class ineens niet zo nuttig meer.

Ik snap de noodzaak van geordende lijstjes waarin je snel wilt zoeken, maar zoals ik al zei: door zelf een IComparer te bouwen en IComparable op je classes te implementeren (wat je uberhaupt zou moeten wanneer er een balanced tree class in .NET zou zitten) heb je al je balanced tree, want dat is verder nog... wat, 10 regels code?

Ook moet men niet de STD met .NET vergelijken. De STD maakt gebruik van C++ generics, .NET heeft geeneens generics (ja in de volgende versie, en dan nog niet eens vergelijkbare generics), dus die libs vergelijken lijkt me onzinnig. Het is ook niet echt nodig: je kunt ook kijken naar wat je NODIG hebt. Een balanced tree bouwen met IComparable en IComparer is erg makkelijk, en met een class derived van hashtable heb je je buckets ook meteen klaar.

En als je niet geinteresseerd bent om het zelf te maken, dan kijk je toch even op code project?
http://www.codeproject.com/csharp/#Data+Structures
en dan vind je bv: http://www.codeproject.com/csharp/sets.asp

Zoals ik al eerder zei: er is veel discussie geweest waarom er bv niet een linked list structure in .NET zit, en er valt wat voor te zeggen, maar zonder generics zul je toch veel werk zelf moeten doen, wat neerkomt op het leeuwendeel zelf schrijven.

[ Voor 5% gewijzigd door EfBe op 22-07-2005 09:06 ]

[riezebosch]

EfBe schreef op vrijdag 22 juli 2005 @ 09:05:
[...]

Stop maar eens 1000 elements in een arraylist en ga dan maar es zoeken. Linear search! (indexOf, contains... allemaal lopen ze alle elements af en roepen Equals aan)

---------------
Kijk ik snap best dat mensen allerlei structuren willen in het framework, maar men gaat aan het punt voorbij dat wanneer je GEEN generics hebt (en dat is het geval bij .NET 1.x) je middels externe objects je structuur moet bouwen, dus middels een comparer en IComparable implementaties op de values. Dat maakt een 'framework' class ineens niet zo nuttig meer.

Ik snap de noodzaak van geordende lijstjes waarin je snel wilt zoeken, maar zoals ik al zei: door zelf een IComparer te bouwen en IComparable op je classes te implementeren (wat je uberhaupt zou moeten wanneer er een balanced tree class in .NET zou zitten) heb je al je balanced tree, want dat is verder nog... wat, 10 regels code?

Ook moet men niet de STD met .NET vergelijken. De STD maakt gebruik van C++ generics, .NET heeft geeneens generics (ja in de volgende versie, en dan nog niet eens vergelijkbare generics), dus die libs vergelijken lijkt me onzinnig. Het is ook niet echt nodig: je kunt ook kijken naar wat je NODIG hebt. Een balanced tree bouwen met IComparable en IComparer is erg makkelijk, en met een class derived van hashtable heb je je buckets ook meteen klaar.

En als je niet geinteresseerd bent om het zelf te maken, dan kijk je toch even op code project?
http://www.codeproject.com/csharp/#Data+Structures
en dan vind je bv: http://www.codeproject.com/csharp/sets.asp

Zoals ik al eerder zei: er is veel discussie geweest waarom er bv niet een linked list structure in .NET zit, en er valt wat voor te zeggen, maar zonder generics zul je toch veel werk zelf moeten doen, wat neerkomt op het leeuwendeel zelf schrijven.

Een (normale) Tree had ik inderdaad ook zo gebouwd, op basis van een ArrayList Point taken

[.oisyn]

EfBe schreef op vrijdag 22 juli 2005 @ 09:05:
Kijk ik snap best dat mensen allerlei structuren willen in het framework, maar men gaat aan het punt voorbij dat wanneer je GEEN generics hebt (en dat is het geval bij .NET 1.x) je middels externe objects je structuur moet bouwen, dus middels een comparer en IComparable implementaties op de values. Dat maakt een 'framework' class ineens niet zo nuttig meer.

Ik zie niet in hoe je die externe objecten / interfaces niet nodig zou hebben als je wel generics gebruikt. Het zijn nog altijd geen C++ templates, en comparison operator overloading is er ook niet bij. En ja, zelfs std::map & co uit C++ werkt met die externe objecten, die defaulten naar een std::less<key_type>, die weer een default implementatie heeft die simpelweg de < operator gebruikt.

Ik snap de noodzaak van geordende lijstjes waarin je snel wilt zoeken, maar zoals ik al zei: door zelf een IComparer te bouwen en IComparable op je classes te implementeren (wat je uberhaupt zou moeten wanneer er een balanced tree class in .NET zou zitten) heb je al je balanced tree

Onzin natuurlijk, met die objecten heb je een manier om compares te doen, niets meer en niets minder. De verdere hele tree implementatie (insertion, deletion, balancing, searching, iterators) afdoen als slechts 10 regels code vind ik nogal kort door de bocht.

Ook moet men niet de STD met .NET vergelijken

STL

De STD maakt gebruik van C++ generics, .NET heeft geeneens generics (ja in de volgende versie, en dan nog niet eens vergelijkbare generics), dus die libs vergelijken lijkt me onzinnig. Het is ook niet echt nodig: je kunt ook kijken naar wat je NODIG hebt. Een balanced tree bouwen met IComparable en IComparer is erg makkelijk, en met een class derived van hashtable heb je je buckets ook meteen klaar.

Waarom dan wel een hashtable implementatie maar geen balanced tree implementatie? Ik zie niet echt een verschil tussen de twee op gebied van implementatie-moeilijkheid oid. Volgens jouw zelfde argumentatie is een hashtable implementatie in .Net ook overbodig. Zelfs een ArrayList implementatie is overbodig (ook slechts 10 regels code).

Zoals ik al eerder zei: er is veel discussie geweest waarom er bv niet een linked list structure in .NET zit, en er valt wat voor te zeggen, maar zonder generics zul je toch veel werk zelf moeten doen, wat neerkomt op het leeuwendeel zelf schrijven.

Nee, het enige wat je hoeft te doen is hier en daar wat casten, dat vind ik nou niet bepaald "het leeuwendeel zelf schrijven". Daarnaast vind ik je linked list een beetje slecht voorbeeld, met een ArrayList kun je precies hetzelfde (dus afgezien van wat performance voor- en nadelen heb je een alternatieve structuur die ook kan opslaan wat je op wilt slaan). Maar er bestaat geen alternatieve structuur voor een binary tree, terwijl het imho net zo'n basisstructuur is als een ArrayList.

[ Voor 4% gewijzigd door .oisyn op 22-07-2005 13:56 ]

[alienfruit]

Sinds wanneer kan je de Equals, LessThan, operators niet overloaden?

code:

// equals // ==
class operator Equals(...);

Werkt gewoon in Chrome... Net als generics zouden kunnen werken in .NET 1.0, zolang je maar je eigen implementatie maakt, wat niet slim is

[ Voor 42% gewijzigd door alienfruit op 22-07-2005 14:39 ]

[.oisyn]

Mijn fout, dacht dat operator overloading in C# niet mogelijk was.

[alienfruit]

Geen enkel probleem, maar heeft de topic starter nu zijn balanced tree ?

[MrBucket]

alienfruit schreef op vrijdag 22 juli 2005 @ 16:24:
Geen enkel probleem, maar heeft de topic starter nu zijn balanced tree ?

Jazekers, ik gebruik nu die van CodeProject, omdat die me wel goed gestructureerd lijkt en bovendien erg volledig is.

En van wat ik zo kan zien werkt het prima

[MSalters]

.oisyn schreef op donderdag 21 juli 2005 @ 14:56:
C++ kent dan ook de lower_bound() en upper_bound() functies voor de set en map varianten. lower_bound() retourneert het eerste element waarvoor geldt element >= key en upper_bound doet een element > key. Op die manier kun je dus 2 iterators krijgen binnen een bepaalde range.

Wat een hele kunst is, gezien het feit dat element alleen een less<T> hoeft te hebben

Serieus: het probleem met dit soort containers is dat je een problematische balans hebt tussen efficientie enerzijds en flexibiliteit anderzijds. Als je vergelijkingsfunctie runtime in te stellen is, dan heb je heleboel relatief dure calls (niet inlined), is het fixed dan heb je typisch alleen <. Je hebt C++ templates nodig om compile-time flexibiliteit te combineren met efficientie.

[.oisyn]

Nee niet heleboel, slechts ²log N calls. En bovendien is het maar betrekkelijk, de call is slechts een kleine overhead, de structuur zelf is al de grootste optimalisatie. Het zal bij veel elementen altijd sneller zijn dan insertion, deletion en searching in een ArrayList, en dát is uiteindelijk waar het om gaat bij de datastructuur, niet dat je call overheads weg gaat werken (als je je daar zorgen om maakt moet je idd geen C# gebruiken maar C++)

[alienfruit]

Naja, als we het toch hebben over snel etc. Kijk eens naar:
http://blogs.msdn.com/ricom/archive/2005/06/30/434534.aspx

[EfBe]

.oisyn schreef op vrijdag 22 juli 2005 @ 13:54:
[...]
Onzin natuurlijk, met die objecten heb je een manier om compares te doen, niets meer en niets minder. De verdere hele tree implementatie (insertion, deletion, balancing, searching, iterators) afdoen als slechts 10 regels code vind ik nogal kort door de bocht.

De IComparer levert je -1, 0 of 1, dus of het element links, in hetzelfde bakje of rechts moet. Nou weet ik het niet, maar dat is de basis van je tree bouw / maintenance routine dacht ik zo. Via recursie kun je dan vrij compact de hap opzetten.

Iterators wordt wat lastig zonder yield, in Jesse Liberty's boek over .NET 2.0 heeft hij wel een mooie gemaakt met de nieuwe interator functionaliteit in .NET 2.0 en een linked list.

[...]
STL

[...]
Waarom dan wel een hashtable implementatie maar geen balanced tree implementatie? Ik zie niet echt een verschil tussen de twee op gebied van implementatie-moeilijkheid oid. Volgens jouw zelfde argumentatie is een hashtable implementatie in .Net ook overbodig. Zelfs een ArrayList implementatie is overbodig (ook slechts 10 regels code).

Het punt is dat een arraylist en een hashtable outofthebox werken, i.e.: zonder IComparable en zonder IComparer. Ze werken wel met die interfaces mocht je meer flexibiliteit willen, maar dat hoeven ze niet.

Een balanced tree HEEFT die interface implementaties nodig, anders kun je de elements niet comparen.

[...]
Nee, het enige wat je hoeft te doen is hier en daar wat casten, dat vind ik nou niet bepaald "het leeuwendeel zelf schrijven". Daarnaast vind ik je linked list een beetje slecht voorbeeld, met een ArrayList kun je precies hetzelfde (dus afgezien van wat performance voor- en nadelen heb je een alternatieve structuur die ook kan opslaan wat je op wilt slaan). Maar er bestaat geen alternatieve structuur voor een binary tree, terwijl het imho net zo'n basisstructuur is als een ArrayList.

ArrayList is een dyn. array, meer niet hoor geen linked node structuur.

Nogmaals, ik snap best dat er soms noodzaak voor is, maar dan bouw je die zelf of trekt er een van de plank(==google). OOKAL omdat je toch veel werk moet doen, ivm die IComparer en IComparable. Nu is 2 ints vergelijken niet zo lastig, maar 2 objects vergelijken, dan moet je wellicht values gaan vergelijken, bv PK fields, en dan moet je bv compound pk's gaan vergelijken, allemaal narigheid waar je zelf iets aan moet doen. Zodra je dat dan klaar hebt kun je met je eigenlijke structuur aan de gang en die is dan echt zo uit te schrijven. Tuurlijk was het handig geweest als er een tree structure class was meegeleverd, maar dat heeft men niet gedaan, mede om de reden dat het niet direct bruikbaar was, je moet eerst zelf wat doen.

Ik moet zeggen dat ik het gezemel over 'dit zit er niet in!!' nooit zo begrijp. In vroeger tijden had je stdlib en nog wat onzin en dat was het wel. Ik heb nu maar eens een Hashtable derived class gemaakt die met dupes overweg kan in hashes, dus buckets heeft per hashcode, dus je kunt meerdere values per hashkey opslaan. Ik kan dan klagen waarom zoiets er niet inzit, ik kan ook de 20 of wat is het, regels code intikken en dan heb ik de structuur zelf. Tuurlijk, het zou mooi zijn als die class er al ingezeten had, maar dat kun je natuurlijk ook van vele andere classes zeggen die je dagelijks moet schrijven.

[farlane]

EfBe schreef op vrijdag 22 juli 2005 @ 23:01:
Ik moet zeggen dat ik het gezemel over 'dit zit er niet in!!' nooit zo begrijp. In vroeger tijden had je stdlib en nog wat onzin en dat was het wel.

Je moet toch toegeve dat ipv al het gefriemel met eigen implementaties ( hoeveel string classes zijn er wel niet geschreven? al is dat niet echt een onderdeel van de generic containers v/d STL ) vooral de communicatie met collega's etc door de STL een heel stuk makkelijker is geworden.

[EfBe]

farlane schreef op maandag 25 juli 2005 @ 09:20:
[...]
Je moet toch toegeve dat ipv al het gefriemel met eigen implementaties ( hoeveel string classes zijn er wel niet geschreven? al is dat niet echt een onderdeel van de generic containers v/d STL ) vooral de communicatie met collega's etc door de STL een heel stuk makkelijker is geworden.

Maar dat kan ook met een intern geschreven library, of class-set, bv een library die gebruikt wordt in het project als zijnde 'utility classes'. Punt blijft dat je weet ik wat wel in .NET kunt stoppen maar het houdt een keer op. De een zal dan zeggen "ja maar een set HOORT er in", terwijl een ander nooit met een set werkt of nodig heeft en iets anders wil.

[alienfruit]

Ja, en als alles er al in .NET zit.... dan kan ik als third party developer ook niks meer ervoor maken

[ Voor 7% gewijzigd door alienfruit op 25-07-2005 10:07 ]

[EfBe]

Jawel . MS is nou niet bijster goed in het bouwen van framework die ALLES kunnen. Ze kunnen altijd 'een beetje van alles', maar specialistisch werk is veelal niet aan die frameworks besteed. Is ook niet erg, want daar zijn ze ook niet voor. Zoals ze dat zelf noemen "3rd party opportunities"

[ Voor 95% gewijzigd door EfBe op 25-07-2005 13:21 ]