C#: Voordelen en nadelen?

[Anoniem: 59155]

Omdat in mijn Java topicje al enkele malen de taal C# is gevallen ben ik hier ook wel in geinteresseerd.

Ik heb nooit ook maar een beetje aandacht aan deze taal willen besteden omdat ie van Microsoft is (sja vooroordelen) maar ik ben toch wel benieuwd wat jullie nu juist handig en juist lastig aan deze taal vinden.

[mbravenboer]

RRazoRR het: Omdat in mijn Java topicje al enkele malen de taal C# is gevallen ben ik hier ook wel in geinteresseerd.

Hum.... het lijkt mij eigenlijk niet zo handig om voor alles wat nieuw voor je is maar gelijk hier een discussie-topic te openen. Neem liever aktief deel aan de discussie die je opende en raadpleeg eerst de search en formuleer een eigen mening. C# is al erg vaak besproken en het lijkt mij wat zonde van de tijd om dat iedere keer opnieuw te gaan doen als iemand C# 'ontdekt'.

Ik heb nooit ook maar een beetje aandacht aan deze taal willen besteden omdat ie van Microsoft is.

Dat lijkt mij een weinig zinvolle reden in ieder geval...

[elnino]

Op dinsdag 02 juli 2002 00:24 schreef RRazoRR het volgende:
Ik heb nooit ook maar een beetje aandacht aan deze taal willen besteden omdat ie van Microsoft is (sja vooroordelen) maar ik ben toch wel benieuwd wat jullie nu juist handig en juist lastig aan deze taal vinden.

En je wilde Java ook al niet proberen, omdat het van Sun was? Welke taal wil je dan?

Maar ik denk dat je het beste op internet kunt zoeken naar meer informatie over C#. C# is overigens gratis te verkrijgen via de .NET Framework SDK, te downloaden bij Microsoft. C# lijkt op Java, btw, en is eigenlijk een soort van verbeterde C++.

Met C# kun je programma's maken voor het zogenaamde Microsoft .NET-platform. Hierover zijn al tig topics geweest. Deze vraag had trouwens misschien ook beter gekund in je andere topic.

[Anoniem: 59155]

Mjah misschien kan ik me idd beter ffkes orrienteren


Wel minders dat je op GoT geen posts/topics van jezelf kan deleten.

Dus modjes: Als jullie het nodig achten, slotje

Mag ook open blijven natuurlijk.
Is wel interessant

[mbravenboer]

elnino: C# is overigens gratis te verkrijgen via de .NET Framework SDK, te downloaden bij Microsoft.

Als je nu echt een ontzettende hekel hebt aan Microsoft of gezegend bent met een *nix machine kan je ook al aardig C# proggelen met Mono: http://www.go-mono.org . Ze hebben nog een lange weg te gaan, zowel qua library als qua runtime als qua compiler, maar een Hello world lukt wel .

C# lijkt op Java, btw, en is eigenlijk een soort van verbeterde C++.

Gevaarlijke opmerkingen .

[elnino]

Op dinsdag 02 juli 2002 00:34 schreef mbravenboer het volgende:
Als je nu echt een ontzettende hekel hebt aan Microsoft of gezegend bent met een *nix machine kan je ook al aardig C# proggelen met Mono: http://www.go-mono.org . Ze hebben nog een lange weg te gaan, zowel qua library als qua runtime als qua compiler, maar een Hello world lukt wel .

Voor beginners leuk, maar al snel wil je dingen met forms enzo doen en dat gaat daarin niet. Maar het is een goed initiatief, wat zeker doorgezet moet worden.

Gevaarlijke opmerkingen .

Ik zeg het natuurlijk alleen zo om voor iemand die er (nog) weinig verstand van heeft uit te leggen wat het verschil is. Uiteraard is er een groot verschil tussen C#, dat ondersteund wordt door het .NET-platform, en Java, dat door het J2EE-platform ondersteund wordt. Maar er zijn ook overeenkomsten en daarom zou je wel kunnen zeggen dat C# (een beetje) op Java lijkt en dat het eigenlijk een verbeterde versie van C++ is, alhoewel C# behoorlijk van C++ verschilt.

[mbravenboer]

elnino: Voor beginners leuk, maar al snel wil je dingen met forms enzo doen en dat gaat daarin niet.

Ik zou geen scheiding willen maken tussen beginners en forms gebruikers, maar goed: ik snap je bedoeling .

Wat dat betreft ben ik eigenlijk erg benieuwd naar de Linux port van Rotor omdat daar alle XML gerelateerde bibliotheken in zitten. Dat geeft je toch wel behoorlijk wat interessante mogelijkheden onder FreeBSD en nu dus ook Linux (als de licentie je niet beperkt, wat in mijn geval volgens mij niet zo is).

[Anoniem: 29256]

Op dinsdag 02 juli 2002 00:42 schreef elnino het volgende:
daarom zou je wel kunnen zeggen dat C# [...] eigenlijk een verbeterde versie van C++ is

Alweer zo'n gevaarlijke opmerking

[Soultaker]

Op dinsdag 02 juli 2002 00:30 schreef elnino het volgende:C# lijkt op Java, btw, en is eigenlijk een soort van verbeterde C++.

C# is een Java-kloon van Microsoft, met vergelijkbare eigenschappen als Java en enkele verschillen. C# heeft net zoveel met C++ te maken als Java dat heeft: het zijn beide objectgeorienteerde talen, maar daar houdt de vergelijking op.

Ik durf niet te zeggen of C# beter is dan Java, of andersom. Wél spreek ik met kracht tegen dat C# beter is dan C++. Het is een heel andere taal en voor het grootste deel van de toepassingen waarvoor op dit moment C++ gebruikt wordt totaal ongeschikt (en voor het resterende deel is C++ waarschijnlijk nog steeds een goede keuze).

[mbravenboer]

Soultaker reageerde op elnino's gevaarlijke opmerkingen

Dat was een kwestie van aftellen .

[Soultaker]

Op dinsdag 02 juli 2002 02:22 schreef mbravenboer het volgende:
Dat was een kwestie van aftellen .

Ik hap graag.

[Anoniem: 7195]

Op dinsdag 02 juli 2002 02:17 schreef Soultaker het volgende:
[..]
C# is een Java-kloon van Microsoft, met vergelijkbare eigenschappen als Java en enkele verschillen. C# heeft net zoveel met C++ te maken als Java dat heeft: het zijn beide objectgeorienteerde talen, maar daar houdt de vergelijking op.

Nee. Qua syntax hebben zowel Java als C# veel leentjebuur gespeeld bij C++. Dat ze OO talen zijn is juist NIET een van de eigenschappen die ze geleend hebben bij C++, immers dat is een hybride taal met een OO-type dat niet matcht met dat van C# of Java.

Ik durf niet te zeggen of C# beter is dan Java, of andersom. Wél spreek ik met kracht tegen dat C# beter is dan C++. Het is een heel andere taal en voor het grootste deel van de toepassingen waarvoor op dit moment C++ gebruikt wordt totaal ongeschikt (en voor het resterende deel is C++ waarschijnlijk nog steeds een goede keuze).

#define beter

Ik vind C++ de meest overgewaardeerde klotetaal die er is. De syntax is zo onnodig complex, dat er niet 1 compiler is die de complete syntaxis ondersteunt. De ideeen erachter zijn wel aardig, bv het hybride gedeelte is voor sommige applicaties een uitkomst omdat niet alles OO te maken is, maar dat 'beter' is veelal terug te voeren op 'maar wat ik maak is niet in <andere taal> te maken, dus is C++ beter'. Ergo: dat is dus alleen voor jou en die situatie zo. Het gros van de applicaties die gebouwd worden op deze aardkloot zijn met C++ langer in development en slechter onderhoudbaar, terwijl C++ niet hogere snelheidswinsten oplevert etc.

[OMX2000]

Op dinsdag 02 juli 2002 09:33 schreef Otis het volgende:

[..]

Nee. Qua syntax hebben zowel Java als C# veel leentjebuur gespeeld bij C++. Dat ze OO talen zijn is juist NIET een van de eigenschappen die ze geleend hebben bij C++, immers dat is een hybride taal met een OO-type dat niet matcht met dat van C# of Java.
[..]

#define beter

Ik vind C++ de meest overgewaardeerde klotetaal die er is. De syntax is zo onnodig complex, dat er niet 1 compiler is die de complete syntaxis ondersteunt. De ideeen erachter zijn wel aardig, bv het hybride gedeelte is voor sommige applicaties een uitkomst omdat niet alles OO te maken is, maar dat 'beter' is veelal terug te voeren op 'maar wat ik maak is niet in <andere taal> te maken, dus is C++ beter'. Ergo: dat is dus alleen voor jou en die situatie zo. Het gros van de applicaties die gebouwd worden op deze aardkloot zijn met C++ langer in development en slechter onderhoudbaar, terwijl C++ niet hogere snelheidswinsten oplevert etc.

Eindelijk iemand waarmee ik het mee eens ben ove C++. Ik vond C op school helemaal geweldig, zelfs de pointers vond ik wel cool (ik kende toen alleen nog Pascal). C++ vond ik mwah... Eventjes leuk, maar het kostte me gewoon teveel energie om er op windows (3.1/3.11) iets fatsoenlijks mee te bouwen.

Voor mij is C# dus een ideale taal, je hoeft geen halsbrekende toeren uit te halen om iets te programmeren. Java is is naar mijn gevoel gelijkwaardig aan C#, en is wat "academischer" als C#, maar dat heb je wel vaker met MS talen (VB)...

[MSalters]

Op dinsdag 02 juli 2002 09:48 schreef OMX2000 het volgende:

[..]

Eindelijk iemand waarmee ik het mee eens ben ove C++. Ik vond C op school helemaal geweldig, zelfs de pointers vond ik wel cool (ik kende toen alleen nog Pascal). C++ vond ik mwah... Eventjes leuk, maar het kostte me gewoon teveel energie om er op windows (3.1/3.11) iets fatsoenlijks mee te bouwen.

Vond ik nou weer leuk, win3.11. Was volledig bezopen natuurlijk, en niet bruikbaar voor serieus werk, maar om gewoon in te proggen was't wel lache.
[/offtopic]

[elnino]

Op dinsdag 02 juli 2002 01:32 schreef Sneechy het volgende:
Alweer zo'n gevaarlijke opmerking

Dingen formuleren is nou niet altijd mijn sterkste kant, maar om even door te gaan over C#, Java en C++ : Microsoft heeft C# ontworpen om een betere versie van C++ te maken. Daarom noem ik het nu ook even 'verbeterd'. Uiteraard zijn er grote verschillen tussen de talen en natuurlijk kun je nooit zeggen dat één taal echt beter is dan een andere, omdat iedere taal weer een andere toepassing en een ander werkgebied heeft. Goed is altijd subjectief.

C++ is, net als C, een taal die dichter bij de processor staat (om het zo maar even te noemen) dan Java en C#. Sommige mensen vinden het een verbetering dat je bij Java en C# geen pointers e.d. hebt en minder gedoe met strings enzo hebt. Maar woorden als 'verbetering' zijn natuurlijk altijd subjectief.

_{niks explosiefs gevonden?}

[Anoniem: 13700]

Op dinsdag 02 juli 2002 09:33 schreef Otis het volgende:
#define beter

Ik vind C++ de meest overgewaardeerde klotetaal die er is. De syntax is zo onnodig complex, dat er niet 1 compiler is die de complete syntaxis ondersteunt. De ideeen erachter zijn wel aardig, bv het hybride gedeelte is voor sommige applicaties een uitkomst omdat niet alles OO te maken is, maar dat 'beter' is veelal terug te voeren op 'maar wat ik maak is niet in <andere taal> te maken, dus is C++ beter'. Ergo: dat is dus alleen voor jou en die situatie zo. Het gros van de applicaties die gebouwd worden op deze aardkloot zijn met C++ langer in development en slechter onderhoudbaar, terwijl C++ niet hogere snelheidswinsten oplevert etc.

#define MENINGEN_VERKOPEN_ALS_FEITEN (OTIS)

Reductio ad absurdum:
Als iets, zoals jij stelt, alleen in C++ te maken is, dan betekent dat dat alle andere talen niet Turing-complete zijn (wat me zeer onwaarschijnlijk lijkt).

C++ apps worden langer ontwikkeld, zijn slechter onderhoudbaar, en zijn niet sneller dan... wat?

[Soultaker]

Over C# kan ik weinig zeggen, aangezien ik me er niet in verdiept heb en alleen op de hoogte ben van de basisbeginselen.

Op dinsdag 02 juli 2002 09:33 schreef Otis het volgende:
Nee. Qua syntax hebben zowel Java als C# veel leentjebuur gespeeld bij C++. Dat ze OO talen zijn is juist NIET een van de eigenschappen die ze geleend hebben bij C++

C++ bezit anders alle OO eigenschappen die Java heeft en meer. In hoeverre deze van C++ geleend zijn kan ik niet zeggen; de in C++ gebruikte OO mechanismen komen in veel andere OO talen terug. Een discussie van 'wie er eerst was' lijkt me niet zo zinnig.

Verdere overeenkomsten zijn de sterke typering van C++, die ook in Java en (ik denk?) C# terugkomen en in andere OO talen soms achterwege gelaten wordt.

#define beter

code:

#define beter(doel, ding1, ding2) \
  ( geschiktheid((doel), (ding1)) \
  > geschiktheid((doel), (ding2)) )

De syntax is zo onnodig complex, dat er niet 1 compiler is die de complete syntaxis ondersteunt.

Daar waren inderdaad wat problemen mee, maar dat wordt steeds beter. Er zit dan ook ontzettend veel functionaliteit in. Dat een Java compiler daar minder last van heeft is niet zo vreemd, aangezien Java als taal veel beperkter is dan C++.

Het is trouwens wel zo dat third-party compilers nog steeds bugs bevatten. De Microsoft compiler is berucht; die mocht niet eens het label 'Java' dragen, maar de Symantec compiler kan er ook wat van: die kon dynamische gebonden functies (een van de meest fundamentele principes van Java!) niet correct afhandelen.

De ideeen erachter zijn wel aardig, bv het hybride gedeelte is voor sommige applicaties een uitkomst omdat niet alles OO te maken is, maar dat 'beter' is veelal terug te voeren op 'maar wat ik maak is niet in <andere taal> te maken, dus is C++ beter'.

Het gaat er meestal niet om waar iets in te maken is, (uiteindelijk is min of meer alles wel in alles te maken), maar wat het meest geschikt is voor het doel. Een taal als C++ is uitermate geschikt voor een breed scala aan toepassingen, mede doordat het een hybride taal is en dus goed te integreren valt met bestaande (veelal op C gebaseerde) API's.

C++ heeft een aanzienlijk aantal voordelen ten opzichte van Java en C# (snel, zuinig met geheugen, onafhankelijk, destructors, enzovoorts) waardoor je moeilijk kunt volhouden dat het gebruik van C++ geen voordelen kan bieden.

Ergo: dat is dus alleen voor jou en die situatie zo. Het gros van de applicaties die gebouwd worden op deze aardkloot zijn met C++ langer in development en slechter onderhoudbaar,

Misschien gaat code kloppen in C# of Java sneller dan in C++. Bij een serieus project neemt de ontwerpfase echter veruit de meeste tijd in beslag, dus zal het weinig uitmaken of de implementatiefase iets langer of korter duurt.

terwijl C++ niet hogere snelheidswinsten oplevert etc.

Dat is simpelweg niet waar. Om met Java vergelijkbare all-round resultaten te benaderen als in C++ zul je zo ontzettend veel moeten optimaliseren dat het veel makkelijker was geweest om gelijk C++ te programmeren.

[whoami]

Op dinsdag 02 juli 2002 13:40 schreef Soultaker het volgende:

C++ bezit anders alle OO eigenschappen die Java heeft en meer. In hoeverre deze van C++ geleend zijn kan ik niet zeggen; de in C++ gebruikte OO mechanismen komen in veel andere OO talen terug.

Volgens mij moet iedere taal die zich OO wil noemen aan een aantal basis mechanismen van OO voldoen.
Daarom kun je bv niet zeggen dat C++ eerst was met bv inheritance, want inheritance is een aspect van OO en niet geintroduceerd door C++. _{Of wat bedoelde je wat anders met dat stukje?}

Verdere overeenkomsten zijn de sterke typering van C++, die ook in Java en (ik denk?) C# terugkomen en in andere OO talen soms achterwege gelaten wordt.

C# is, net als Java type-safe/strong typed. C++ is dat toch in mindere mate denk ik.

[Soultaker]

Op dinsdag 02 juli 2002 13:46 schreef whoami het volgende:
Volgens mij moet iedere taal die zich OO wil noemen aan een aantal basis mechanismen van OO voldoen.
Daarom kun je bv niet zeggen dat C++ eerst was met bv inheritance, want inheritance is een aspect van OO en niet geintroduceerd door C++. _{Of wat bedoelde je wat anders met dat stukje?}

Uhm nee, zoals ik een paar regels verderop ( ) aangaf, wilde ik daarmee zeggen, wat jij ook zegt: bepaalde eigenschappen zijn zo algemeen voor OO talen, dat het niet redelijk is om te zeggen dat omdat C# sommige van dezelfde eigenschappen heeft als C++, C# als verbetering van C++ is ontworpen.

C++ was zeker niet de eerste OO taal; talen als Simula, SmallTalk, Eiffel (in die volgorde, denk ik?) waren veel eerder. Maar daar gaat de discussie natuurlijk niet over.

C# is, net als Java type-safe/strong typed. C++ is dat toch in mindere mate denk ik.

In C++ kun je nog steeds C-style casts aanroepen. Als je puur C++ programmeert, gebruik je uitsluitend C++-style casts en die zijn in het algemeen type safe. In Java kun je ook nog typecasten, wat te vergelijken is met de C++ dynamic_cast. Het is sowieso bad practice om casts te gebruiken om een ontwerp werkend te krijgen, als je het mij vraagt.

Het is in ieder geval duidelijk dat C++ ontzettend veel beter met typen omgaat dan bijvoorbeeld Smalltalk, dat eigenlijk helemaal niet aan typen doet. Elk C++ progamma is gegarandeert compile-time typesafe, tenzij je zelf expliciet door middel van casts de boel in de war schopt.

[Anoniem: 7195]

Op dinsdag 02 juli 2002 12:29 schreef mietje het volgende:
[..]
#define MENINGEN_VERKOPEN_ALS_FEITEN (OTIS)

Nee. C++ maakt code onnodig complex door het toestaan van templates en obscure operator overloading mogelijkheden.

Reductio ad absurdum:
Als iets, zoals jij stelt, alleen in C++ te maken is, dan betekent dat dat alle andere talen niet Turing-complete zijn (wat me zeer onwaarschijnlijk lijkt).

Ik bedoel: de output van de compiler is code die sneller executeert, wat bv voor 3D app makers interessant is. C++ is echt geen unieke taal, dat weet ik zelf ook wel.

C++ apps worden langer ontwikkeld, zijn slechter onderhoudbaar, en zijn niet sneller dan... wat?

Veel applicaties die worden ontwikkeld zijn zg. client - server applicaties, waar C++ niet noemenswaardige snelheidswinsten oplevert, omdat bottlenecks ergens anders zitten. Talen die de developer afschermen van obscuriteiten maar wel een krachtige expressiviteit hebben genieten dan de voorkeur, daar je met simpelere code even snelle applicaties kunt bouwen die makkelijker onderhoudbaar zijn door meer mensen. Voorbeeld: data-access tier object in n-tier app gemaakt in VB en in C++.

[Anoniem: 7195]

Op dinsdag 02 juli 2002 13:40 schreef Soultaker het volgende:
Over C# kan ik weinig zeggen, aangezien ik me er niet in verdiept heb en alleen op de hoogte ben van de basisbeginselen.

Je deed hierboven anders een uitspraak mbt de relatie tussen C# en C++ en Java. Die is dus behoorlijk op drijfzand gebaseerd zo lijkt het.

[..]
C++ bezit anders alle OO eigenschappen die Java heeft en meer. In hoeverre deze van C++ geleend zijn kan ik niet zeggen; de in C++ gebruikte OO mechanismen komen in veel andere OO talen terug. Een discussie van 'wie er eerst was' lijkt me niet zo zinnig.

Nee, want dan kom je al snel bij smalltalk e.d. uit. De in C++ gebouwde OO eigenschappen als multiple inheritence komen niet in veel talen terug, veel talen gebruiken slechts single inheritence. Polymorphism e.d. zijn geen C++ eigenschappen zodanig dat andere talen die dat ook hebben DUS C++ als voorbeeld hebben genomen, in tegendeel.

Verdere overeenkomsten zijn de sterke typering van C++, die ook in Java en (ik denk?) C# terugkomen en in andere OO talen soms achterwege gelaten wordt.

C++ is helemaal niet zo typesafe, C# daarentegen wel. In C# heb je bv geen pointers, in C++ kun je elke willekeurige pointer naar iets casten (C-style). Lijkt me niet erg sterke typering.

[..]
Daar waren inderdaad wat problemen mee, maar dat wordt steeds beter. Er zit dan ook ontzettend veel functionaliteit in. Dat een Java compiler daar minder last van heeft is niet zo vreemd, aangezien Java als taal veel beperkter is dan C++.

Onzin. De dingen die niet in C# en java zitten zijn templates, iets wat niets meer is dan een at-compiletime code generator en de reden dat de taal onbruikbaar is in veel gevallen en sommige zielen de illustere gedachte geeft superieur te zijn omdat ze de syntax voor meer dan de helft begrijpen.

Deze zaken heb je echter in geen geval nodig. Ik heb in C++ nooit 1 template nodig gehad, hoogstens gebruikt mbv de STL, maar ik blijf het gekunstel vinden. Goede classtrees zorgen ervoor dat je geen templates nodig hebt.

C#, Java en zelfs VB, hebben allemaal meer dan voldoende functionaliteit om alle mogelijke applicaties te maken. Dat geeft aan dat C++ onnodig complex is. Want de leercurve voor de complete syntaxis is dermate stijl dat het kiezen voor C++ lang niet altijd te verdedigen is, wanneer je kijkt naar concurrerende talen, zoals C# en Java.

[..]
Het gaat er meestal niet om waar iets in te maken is, (uiteindelijk is min of meer alles wel in alles te maken), maar wat het meest geschikt is voor het doel. Een taal als C++ is uitermate geschikt voor een breed scala aan toepassingen, mede doordat het een hybride taal is en dus goed te integreren valt met bestaande (veelal op C gebaseerde) API's.

C api's kun je ook heel gemakkelijk vanuit C# gebruiken. De 'C' syntax in C++ is vrij gemakkelijk te doorgronden, de echte C++ syntax, waardoor C++ voordelen kan hebben, is dat echter niet. In C++ is alles te maken, maar IMHO is het een taal die erg weinig ECHT geschikt is voor veel toepassingen. Zeker met het oog op de concurrerende talen die de developer afschermen voor onnodige truttigheid als overhead mbt references etc. In C++ schrijf je dus veel meer code terwijl dat allemaal onnodige troep is, de algoritmes zelf is waar je je mee bezig wilt houden, de rest is onnodige ballast, die zo klein mogelijk moet worden gehouden.

C++ heeft een aanzienlijk aantal voordelen ten opzichte van Java en C# (snel, zuinig met geheugen, onafhankelijk, destructors, enzovoorts) waardoor je moeilijk kunt volhouden dat het gebruik van C++ geen voordelen kan bieden.

Dat 'snel' is maar betrekkelijk. Een data-access tier com object in C++ is echt niet sneller dan zn C# tegenvoeter. Die C# tegenvoeter is echter wel in een fractie van de tijd geschreven, en simpel te lezen en dus te onderhouden. Zuinig met geheugen lijkt me niet iets wat aan een 'taal' geplakt kan worden, maar hangt puur af van de RTE. C# heeft overigens ook destructors, maar wat isdat voor voordeel?

[..]
Misschien gaat code kloppen in C# of Java sneller dan in C++. Bij een serieus project neemt de ontwerpfase echter veruit de meeste tijd in beslag, dus zal het weinig uitmaken of de implementatiefase iets langer of korter duurt.

Mensen die totaal ingeleefd zijn in C++ zijn er snel mee, de meeste mensen echter zijn dat niet en doen er schrikbarend langer over om een goed werkend programma af te leveren. Niet verwonderlijk, je moet met erg veel dingen rekening houden die buiten de functionaliteit vallen die je feitelijk moet implementeren. Je ontwerpfase duurt bij een groot project wel lang, maar met een taal die erg veel tijd kost om alle code in te schrijven, duurt de implementatiefase ook lang, de testfase duurt lang (want alle overhead code is ook met de hand geschreven!) en de onderhoudstijd is veel hoger: alleen de echte ingewijde kan doorgronden wat de programmatekst voorstelt. Bij talen als Java en C# heb je daar veel minder last van.

[Otis: terwijl C++ niet hogere snelheidswinsten oplevert etc.]
Dat is simpelweg niet waar. Om met Java vergelijkbare all-round resultaten te benaderen als in C++ zul je zo ontzettend veel moeten optimaliseren dat het veel makkelijker was geweest om gelijk C++ te programmeren.

Een COM component dat een recordset uit een database trekt door het aanroepen van een stored proc, iets doet met die recordset en dan de handel doorgeeft aan een andere layer of weer een stored proc aanroept voor verdere dataverwerking, of bv een ander com component aanroept en een transaction start, het boeit echt geen donder of je dat nu in VB doet of in C++. Een GUI bouwen in C++ is bv ook onnozel, in talen als VB ben je veel sneller klaar. Snelheidsverlies? Dacht het niet: de meeste code die ge-executeerd wordt is OS code, geen applicatiecode.

OpenGL programmeren is wellicht wel sneller in C++, alhoewel ook daar je vraagtekens moet zetten bij het geheel: een beetje goed geschreven 3D engine laat zoveel mogelijk de driver en 3d hardware de functionaliteit uitvoeren. Wat overblijft is een scenegraph die wellicht in C++ sneller is dan in bv C#, maar is dat een verdienste van C++?

Nee. Dat is een verdienste van de native compiler van C++. Het wachten is op de dag dat de C# jitcompiler's native code net zo snel is als C++ code. En ik verzeker je: die dag komt met rasse schreden dichterbij.

[Anoniem: 7195]

Op dinsdag 02 juli 2002 13:57 schreef Soultaker het volgende:
C++ was zeker niet de eerste OO taal; talen als Simula, SmallTalk, Eiffel (in die volgorde, denk ik?) waren veel eerder. Maar daar gaat de discussie natuurlijk niet over.

Eiffel is van na 1992 dacht ik.

[..]
In C++ kun je nog steeds C-style casts aanroepen. Als je puur C++ programmeert, gebruik je uitsluitend C++-style casts en die zijn in het algemeen type safe. In Java kun je ook nog typecasten, wat te vergelijken is met de C++ dynamic_cast. Het is sowieso bad practice om casts te gebruiken om een ontwerp werkend te krijgen, als je het mij vraagt.

huh? Hoe wil je anders een uniform object maken dat verschillende van eenzelfde baseclass derivede classes kan verwerken? Of, het door jou gepredikte sterke typering systeem van C++?

Als ik een array van objects heb, gederived van de baseclass 'CSoundElement', en ik maak de elements van het array van dat type, dan kan ik alle mogelijke objects van derived classes van CSoundElement daarin stoppen. Als ik nu wil werken met een zo'n element, bv een CMP3Element, hoe leg ik dan een pointer naar dat object? Toch via een cast!:

code:

pMP3Element=dynamic_cast<CMP3Element*>(m_pseSoundElementStore[iElementCodeID]);

Zonder casts kom je er dan niet, of je moet met pointers naar baseclasses werken, maar dan mis je specifieke methods in de derived class, wellicht. Casts zijn dus wel degelijk nodig en met RTTI in C++ goed te gebruiken. Het ziet er niet uit, maar dat is een ander verhaal

Het is in ieder geval duidelijk dat C++ ontzettend veel beter met typen omgaat dan bijvoorbeeld Smalltalk, dat eigenlijk helemaal niet aan typen doet. Elk C++ progamma is gegarandeert compile-time typesafe, tenzij je zelf expliciet door middel van casts de boel in de war schopt.

Nee. Ik kan een blok memory at runtime vullen met getallen en dat casten naar een pointer van een type class. Dan een method aanroepen die niet bestaat. In C# lukt je dat niet. In C++ wel.

[Anoniem: 13700]

No offence Otis, maar lees nu eens je eigen post terug.

Op dinsdag 02 juli 2002 16:29 schreef Otis het volgende:
Onzin. De dingen die niet in C# en java zitten zijn templates, iets wat niets meer is dan een at-compiletime code generator en de reden dat de taal onbruikbaar is in veel gevallen en sommige zielen de illustere gedachte geeft superieur te zijn omdat ze de syntax voor meer dan de helft begrijpen.

Deze zaken heb je echter in geen geval nodig. Ik heb in C++ nooit 1 template nodig gehad, hoogstens gebruikt mbv de STL, maar ik blijf het gekunstel vinden. Goede classtrees zorgen ervoor dat je geen templates nodig hebt.

Otis behandelt generic programming: gekunsteld, niet nodig. Blijkbaar moet Otis zich eens nodig vediepen in generics, want hij begrijpt de voordelen van generics niet.

C#, Java en zelfs VB, hebben allemaal meer dan voldoende functionaliteit om alle mogelijke applicaties te maken. Dat geeft aan dat C++ onnodig complex is.

De constructs die in Java en C++ gebruikt worden, zijn bijna letterlijk het zelfde. De enige zaken waarbij de C++ syntax complex wordt, zijn de features die in Java niet mogelijk zijn.

In C++ is alles te maken, maar IMHO is het een taal die erg weinig ECHT geschikt is voor veel toepassingen.

Vandaar ook dat C++ de meest gebruikte taal is, zelfs meer dan haar concurrenten bij elkaar.

In C++ schrijf je dus veel meer code terwijl dat allemaal onnodige troep is, de algoritmes zelf is waar je je mee bezig wilt houden, de rest is onnodige ballast, die zo klein mogelijk moet worden gehouden.

Je flamed in de zelfde post op C++ als "niet typesafe", maar alles wat de taal safe maakt is "onnodige ballast, truttigheid".

[Soultaker]

Op dinsdag 02 juli 2002 16:40 schreef Otis het volgende:
huh? Hoe wil je anders een uniform object maken dat verschillende van eenzelfde baseclass derivede classes kan verwerken? Of, het door jou gepredikte sterke typering systeem van C++?

Je kunt bij het schrijven van zo'n object nooit alle mogelijke subklassen afvangen (omdat die in theorie niet bekend zijn). In de praktijk kan dit wel, met behulp van de genoemde dynamic_cast, maar dat is hackwerk.

Code die specifiek is voor een zekere klasse, hoort in die klasse te staan en niet in een of andere andere klasse die toevallig met een superklasse van die klasse werkt.

De natuurlijke oplossing is dan ook het subklasse-specifieke werk onderbrengen in de subklasse, zoals bij het visitor pattern gebeurt. De generieke aanroep, die voor elk object hetzelde is, komt dan in de superklasse te staan.

Als je niet gelooft dat dit werkt en beter is, mag je een (bij voorkeur niet al te complexe) casus aandragen waarbij het gebruik van casts een substantieel voordeel oplevert, dat niet op écht OO-wijze verkregen kan worden. Ik zal dan mijn best doen om te laten zien hoe 't ook kan en aan te tonen dat (en waarom) dat beter is.

[Soultaker]

Op dinsdag 02 juli 2002 16:40 schreef Otis het volgende:
Als ik een array van objects heb, gederived van de baseclass 'CSoundElement', en ik maak de elements van het array van dat type, dan kan ik alle mogelijke objects van derived classes van CSoundElement daarin stoppen. Als ik nu wil werken met een zo'n element, bv een CMP3Element, hoe leg ik dan een pointer naar dat object? Toch via een cast!:

code:

pMP3Element=dynamic_cast<CMP3Element*>(m_pseSoundElementStore[iElementCodeID]);

Zonder casts kom je er dan niet, of je moet met pointers naar baseclasses werken, maar dan mis je specifieke methods in de derived class, wellicht. Casts zijn dus wel degelijk nodig en met RTTI in C++ goed te gebruiken. Het ziet er niet uit, maar dat is een ander verhaal

Maar waarom wil je dan zo'n MP3Element hebben? Wat zou je er mee willen doen, dat niet in dat MP3Element zelf kan gebeuren?

Nee. Ik kan een blok memory at runtime vullen met getallen en dat casten naar een pointer van een type class. Dan een method aanroepen die niet bestaat. In C# lukt je dat niet. In C++ wel.

Niet als je je uitsluitend toelegd op C++ mechanismen. Een dynamic_cast failed als het type niet te casten valt. Op die manier is C++ net zo veilig als C#. Je kunt inderdaad, vanwege de C code in C++, rariteiten uithalen met pointers enzo, maar zoals mbravenboer onlangs demonstreerde, kunnen dat soort dingen ook nog in Java (al wordt dat ontzettend afgeraden). C++ gaat uit zichzelf eigenlijk alleen fout op indirectie van ongeinitialiseerde waarden en 0-pointers. Tja, je kunt niet alles at-runtime checken.

Als je je best wilt doen om je applicatie te laten crashen, dan is daar in een fatsoenlijke programmeertaal altijd wel een mechanisme voor.

[Anoniem: 7195]

Op dinsdag 02 juli 2002 16:45 schreef mietje het volgende:
No offence Otis, maar lees nu eens je eigen post terug.

Klopt het niet?

[..]
Otis behandelt generic programming: gekunsteld, niet nodig. Blijkbaar moet Otis zich eens nodig vediepen in generics, want hij begrijpt de voordelen van generics niet.

blaaaaaat.
Wat is je punt? Dat templates nodig zijn? Waarom mist niemand ze in C# of Java? Ik snap de voordelen wel, maar ik zie geen voordeel meer wanneer ik kijk naar de syntactische ellende die ontstaat bij het gebruik van templates in C++ sourcecode, en dan met name wanneer je zelf templates gaat schrijven: sourcecode lezen wordt dermate complex dat je veelal dmv een debugger moet gaan kijken wat templated code werkelijk doet en waar bv een fout zit of waar fouten kunnen ontstaan. Ook daar wordt het snel moeilijk: het debuggen van templates is in veel debuggers een ellende. Maar goed, jij ziet alleen voordelen. Raar, je geeft daarmee aan dat bv talen als C# nu dermate onthand zijn dat ze dat voordeel terdege missen. Echter dat is niet zo.

[..]
De constructs die in Java en C++ gebruikt worden, zijn bijna letterlijk het zelfde. De enige zaken waarbij de C++ syntax complex wordt, zijn de features die in Java niet mogelijk zijn.

Ik heb het over templates en operator overloading syntaxis icm templates. Die is dermate complex dat je code onleesbaar wordt, BEHALVE wanneer je ingewijd bent in de C++ syntax op een hoog niveau en/of zeer ingewijd in de betreffende sourcecode. Nu is het wellicht in jouw wereld zo dat hoe complexer de code hoe beter, maar in mijn wereld is dat niet zo, integendeel. Aangezien ANDERE talen aantonen dat je met een simpelere syntaxis dezelfde expressiekracht krijgt, is automatisch de C++ syntaxis onnodig complex.

[..]
Vandaar ook dat C++ de meest gebruikte taal is, zelfs meer dan haar concurrenten bij elkaar.

Lijkt me erg sterk. Veel software, verreweg de meeste software, wordt niet in C++ geschreven maar in 4GL talen of talen als VB. Maar jij hebt ongetwijfeld bewijzen voorhanden. Ik ben benieuwd.

[..]
Je flamed in de zelfde post op C++ als "niet typesafe", maar alles wat de taal safe maakt is "onnodige ballast, truttigheid".

Sinds wanneer is iets kut vinden met argumenten 'flamen' ? Kennelijk is het afkraken van een computertaal schoppen tegen je heilige huisje.

Verder zie ik de link tussen templates en typesafety niet echt. Zolang ik void pointers kan doorgeven aan functies in C++ is de taal niet typesafe. Of wou je beweren van wel? Voorkomen templates het doorgeven van void pointers en de type-nonsafety die eromheen hangt? Kennelijk...

[Anoniem: 7195]

Op dinsdag 02 juli 2002 17:25 schreef Soultaker het volgende:
[..]
Maar waarom wil je dan zo'n MP3Element hebben? Wat zou je er mee willen doen, dat niet in dat MP3Element zelf kan gebeuren?

Het aanroepen van een overloaded method? Ja klinkt wellicht schokkend in de oren!

[..]
Niet als je je uitsluitend toelegd op C++ mechanismen. Een dynamic_cast failed als het type niet te casten valt.

dynamic_cast maakt gebruik van RTTI: 'RunTime Type Information'. Als ik in memory een vtable aanmaak dan lukt die cast wel degelijk. Ik kan dus ook die vtable omschrijven in memory at runtime. De compiler kan dat niet voorkomen. En wat zijn 'C++ mechanismen' ? Het zit toch in de taal?

Op die manier is C++ net zo veilig als C#. Je kunt inderdaad, vanwege de C code in C++, rariteiten uithalen met pointers enzo, maar zoals mbravenboer onlangs demonstreerde, kunnen dat soort dingen ook nog in Java (al wordt dat ontzettend afgeraden). C++ gaat uit zichzelf eigenlijk alleen fout op indirectie van ongeinitialiseerde waarden en 0-pointers. Tja, je kunt niet alles at-runtime checken.

Daarom is C# ook safer dan Java, qua type-safety. Tuurlijk, wanneer je de platgetrede paden bewandelt dan zal de compiler echt wel gaan gillen wanneer je een assignment oid probeert die incompatible is met de types die bekend zijn bij de compiler. Typesafety gaat er juist om at runtime ellende te vermijden. In C++ lukt dat veel minder, omdat at compiletime niet bepaalt kan worden waar een of andere double pointer naartoe wijst bv.

[Soultaker]

Op dinsdag 02 juli 2002 17:35 schreef Otis het volgende:
Veel software, verreweg de meeste software, wordt niet in C++ geschreven maar in 4GL talen of talen als VB.

VB <--> 4GL???

Verder zie ik de link tussen templates en typesafety niet echt. Zolang ik void pointers kan doorgeven aan functies in C++ is de taal niet typesafe. Of wou je beweren van wel? Voorkomen templates het doorgeven van void pointers en de type-nonsafety die eromheen hangt? Kennelijk...

Wat is het probleem met het doorgeven van void-pointers? Zolang je ze maar niet naar willekeurige typen gaat casten, is er niets mis mee. Juist bij template code zul je in principe niet hoeven casten, omdat je de template parametriseerd met de gewenste typen.

[Anoniem: 7195]

Op dinsdag 02 juli 2002 17:47 schreef Soultaker het volgende:

[..]
VB <--> 4GL???

Er staat toch 'of' !

Dit begint op een willekeurige W&L discussie te lijken waar de jehova's tegen de atheisten aan het zeuren zijn dat god wel bestaat. Lighten up.

[..]
Wat is het probleem met het doorgeven van void-pointers? Zolang je ze maar niet naar willekeurige typen gaat casten, is er niets mis mee. Juist bij template code zul je in principe niet hoeven casten, omdat je de template parametriseerd met de gewenste typen.

Templates zijn codegenerators, dus er rolt at compiletime code uit. Hoe, dat is maar de vraag, behalve als jij al lezende precies weet hoe een template eruit ziet. Void pointers zijn heel handig, maar allerminst typesafe. Dat was toch de issue hier? (en een voordeel van C#, het topic)

[marcusk]

Otis:
C++ is helemaal niet zo typesafe, C# daarentegen wel. In C# heb je bv geen pointers, in C++ kun je elke willekeurige pointer naar iets casten (C-style). Lijkt me niet erg sterke typering.

ahum

[Soultaker]

Op dinsdag 02 juli 2002 17:44 schreef Otis het volgende:
Daarom is C# ook safer dan Java, qua type-safety. Tuurlijk, wanneer je de platgetrede paden bewandelt dan zal de compiler echt wel gaan gillen wanneer je een assignment oid probeert die incompatible is met de types die bekend zijn bij de compiler. Typesafety gaat er juist om at runtime ellende te vermijden. In C++ lukt dat veel minder, omdat at compiletime niet bepaalt kan worden waar een of andere double pointer naartoe wijst bv.

Dit vind ik een slechte argumentatie, die ik meer heb gezien. In C# is het onmogelijk rechtstreeks het datasegment te beanderen. In C++ kan dit wel en als je het doet, kan het voor problemen zorgen. Als je gewoon van je rauwe data afblijft, kan er weinig misgaan (zoals gezegd, ongeinitialiseerde data en 0-pointers daargelaten) en heb je dus vergelijkbaar gedrag als met C#.

Je kunt je C++ code net zo ingewikkeld maken als je zelf wilt. Als je casus eenvoudig is, ben je met een eenvoudig ontwerp en een eenvoudige implementatie klaar. Als je casus ingewikkeld is, heb je in C# een probleem, maar in C++ kun je je casus effectief oplossen.

De C++ mogelijkheden zijn geen 'overhead'; er is goed over nagedacht. Er zijn veel gevallen waarin de betreffende mogelijkheden hun nut bewijzen. Dat je ze niet altijd nodig hebt, is nietemin waar.

Ik ben het verder wel met je eens, dat als je denkt geavanceerde functionaliteit nodig te hebben, de kans aanwezig is dat je ontwerp niet goed in elkaar steekt. Dat kan je echter met elke programmeertaal overkomen.

Vanuit die gedachtengang kan ik je standpunt dus wel begrijpen, maar niet de discussie over type casting, die er lijnrecht tegenover staat.

Om daar op terug te komen:

Het aanroepen van een overloaded method? Ja klinkt wellicht schokkend in de oren!

Met welk doel? Waarom zou je een functie die een algemene superklasse meekrijgt een overloaded methode willen laten uitvoeren? Je kan wel zeggen dat je het gewoon wil, maar mijn punt is juist, dat het zelden tot nooit noodzakelijk is, als je een geschikt ontwerp opgestelt hebt.

_{Ik neem trouwens aan dat je met 'overloaded' een methode bedoelt die niet in de superklasse voorkomt (ten opzichte van een echte overloaded methode, die dezelfde naam heeft als een bestaande methode).}

[Anoniem: 7195]

Op dinsdag 02 juli 2002 17:56 schreef marcusk het volgende:

[..]

ahum

Jaja
'unsafe' heet het keyword. Joh, waarom zou dat zijn

[marcusk]

Op dinsdag 02 juli 2002 17:58 schreef Otis het volgende:
Jaja
'unsafe' heet het keyword. Joh, waarom zou dat zijn

Klopt... maar C# heeft dus wel degelijk pointers

[Anoniem: 7195]

Op dinsdag 02 juli 2002 17:56 schreef Soultaker het volgende:
[..]
Dit vind ik een slechte argumentatie, die ik meer heb gezien. In C# is het onmogelijk rechtstreeks het datasegment te beanderen. In C++ kan dit wel en als je het doet, kan het voor problemen zorgen. Als je gewoon van je rauwe data afblijft, kan er weinig misgaan (zoals gezegd, ongeinitialiseerde data en 0-pointers daargelaten) en heb je dus vergelijkbaar gedrag als met C#.

Tuurlijk. Ik beweer ook niet dat het erg bar gesteld is met type-checking in C++ compilers oid. Echter, dit gelul ontstond toen werd beweerd dat de sterke typering van C++ een van de kenmerken was die teruggevonden werd in C#, iets dat ik dus echt niet zo zie. Niet dat C++ slecht is in dat opzicht, maar C#'s typering is onvergelijkbaar met C++'s.

Je kunt je C++ code net zo ingewikkeld maken als je zelf wilt. Als je casus eenvoudig is, ben je met een eenvoudig ontwerp en een eenvoudige implementatie klaar. Als je casus ingewikkeld is, heb je in C# een probleem, maar in C++ kun je je casus effectief oplossen.

Ja het standaard gelul van de C++ programmeur die vindt dat zijn taal superieur is aan andere talen 'want die kunnen veel niet'. Jouw redenatie doortrekkende, is het dus zo dat C++ een slechte keuze is, want in assembler kun je het efficienter oplossen.

De C++ mogelijkheden zijn geen 'overhead'; er is goed over nagedacht. Er zijn veel gevallen waarin de betreffende mogelijkheden hun nut bewijzen. Dat je ze niet altijd nodig hebt, is nietemin waar.

Bijna nooit heb je ze nodig. Er is niet voor niets iets als 'smart pointers', iets dat niet eens in C++ zit als taalelement, maar wel onontbeerlijk in veel gevallen. De reden? -> veel minder overhead, dus veel minder kans op fouten dus veel betere software.

Toen ik DemoGL schreef, een 32.000 regelig OpenGL framework in C/C++, heb ik geen moment nagedacht over een andere taal dan C++ met stukken C. Waarom ook. Toen ik laatst voor een klant een importer moest maken om platte ascii tables afkomstig van een AS/400 in een SQLServer database te migreren, dacht ik eerst aan VB, de overhead zit hem bij database applicaties veelal in de database, niet in de client. De tool zelf was snel geschreven, want weinig overhead code, maar de performance van de textreader liet te wensen over, tijdens een pilotrun. Ik heb de tool opnieuw in C++ geschreven, en de ADO code is ong 2x zo groot als de VB equivalent, met IMHO minder leesbare constructies, maar de textreader is supersnel, de algehele performance is nu veel hoger, omdat de overhead op de client niet noemenswaardig is. Ik _weet_ dat C++ soms voordelen heeft, maar wat 'voordeel' inhoudt is subjectief: lang niet altijd houdt dat in 'snellere executie'. Veelal kiest men voor een compromis tussen snelheid en ontwikkeltijd/onderhoudbaarheid. Ook dat is 'voordeel', een kortere ontwikkeltijd en goede onderhoudbaarheid. En in 8 jaar professioneel software development ben ik nog

Ik ben het verder wel met je eens, dat als je denkt geavanceerde functionaliteit nodig te hebben, de kans aanwezig is dat je ontwerp niet goed in elkaar steekt. Dat kan je echter met elke programmeertaal overkomen.

Precies. Mij hoor je ook niet beweren dat je in C# of erger: in VB geen complexe code kunt fabriceren. Echter de noodzaak is er veel minder, domweg omdat het construeren van code om een algoritme te bouwen zonder complexe syntaxis hoeft.

Vanuit die gedachtengang kan ik je standpunt dus wel begrijpen, maar niet de discussie over type casting, die er lijnrecht tegenover staat.
Om daar op terug te komen:
[stukje code]
Met welk doel? Waarom zou je een functie die een algemene superklasse meekrijgt een overloaded methode willen laten uitvoeren? Je kan wel zeggen dat je het gewoon wil, maar mijn punt is juist, dat het zelden tot nooit noodzakelijk is, als je een geschikt ontwerp opgestelt hebt.

Dit is uit de functie die een soundelement start. Die wordt aangeroepen door een scriptengine. Door de cast en inheritence is het simpel in elkaar te zetten.

edit:

(Ja met 'overloaded' bedoel ik een method die in een derived class een virtual method in de base class overload, vergeef me de mix-up met termen. Is overrided beter? )

Verder zou ik je willen aanraden eens Don Box' Essential Com te lezen, als je iets tegen casts hebt hehe

[.oisyn]

Op dinsdag 02 juli 2002 17:35 schreef Otis het volgende:


Wat is je punt? Dat templates nodig zijn? Waarom mist niemand ze in C# of Java?

dat jij ze niet mist wil niet meteen zeggen dat niemand ze mist. Want waarom zou Java Generics anders bestaan, om maar even een zijstraat in te slaan?
Imho zijn templates uitermate geschikt voor gebruik bij collections: je kunt op die manier elk mogelijke type in je collection stoppen zonder dat je daarbij eisen hoeft te stellen aan het type dat je erin stopt, bijvoorbeeld dat het een subclass van XXX moet zijn of dat ie interface YYY moet implementeren.
Dat jij het niet leesbaar vindt en dat debuggen moeilijk gaat ligt denk ik toch meer aan jezelf... ik heb er nog nooit last van gehad (anders dan de bugs in de MSVC compiler)

[Anoniem: 7195]

Op dinsdag 02 juli 2002 18:17 schreef .oisyn het volgende:
[..]
dat jij ze niet mist wil niet meteen zeggen dat niemand ze mist. Want waarom zou Java Generics anders bestaan, om maar even een zijstraat in te slaan?

De 'functionaliteit' die generics brengt is best handig. Hoe het in C++ is geimplementeerd vind ik niet werkbaar, tenminste wanneer je er stevig gebruik van gaat maken. (ik ben daarin overigens lang niet de enige, bv de developer van Unreal, Tim Sweeney zegt hetzelfde).

Imho zijn templates uitermate geschikt voor gebruik bij collections: je kunt op die manier elk mogelijke type in je collection stoppen zonder dat je daarbij eisen hoeft te stellen aan het type dat je erin stopt, bijvoorbeeld dat het een subclass van XXX moet zijn of dat ie interface YYY moet implementeren.

Ik vind die eisen helemaal niet vervelend, temeer omdat je daarmee typesafety afdwingt en in bv C# je ze ook niet nodig hebt: je kunt bv een collection van 'Object' objects maken, de baseclass of all. Zonder 1 template toch de functionaliteit. En dus zonder gemier met complexe syntaxis. Toegegeven, collections van 'Object' objects, zijn niet zo bar compiletime-typesafe, waardoor je at runtime ellende krijgen kunt, maar indien je dat toch wilt stel je de eisen zoals het implementeren van een zekere interface.

Dat jij het niet leesbaar vindt en dat debuggen moeilijk gaat ligt denk ik toch meer aan jezelf... ik heb er nog nooit last van gehad (anders dan de bugs in de MSVC compiler)

Maar jij beweert dus dat veel C++ developers veel templatecode gewoon kunnen lezen? Ik denk dat maar een fractie de complete STL code begrijpt, om maar iets te noemen.

[.oisyn]

Op dinsdag 02 juli 2002 18:28 schreef Otis het volgende:

[..]

De 'functionaliteit' die generics brengt is best handig. Hoe het in C++ is geimplementeerd vind ik niet werkbaar, tenminste wanneer je er stevig gebruik van gaat maken. (ik ben daarin overigens lang niet de enige, bv de developer van Unreal, Tim Sweeney zegt hetzelfde).

tja, meningen verschillen

Ik vind die eisen helemaal niet vervelend, temeer omdat je daarmee typesafety afdwingt en in bv C# je ze ook niet nodig hebt: je kunt bv een collection van 'Object' objects maken, de baseclass of all. Zonder 1 template toch de functionaliteit. En dus zonder gemier met complexe syntaxis. Toegegeven, collections van 'Object' objects, zijn niet zo bar compiletime-typesafe, waardoor je at runtime ellende krijgen kunt, maar indien je dat toch wilt stel je de eisen zoals het implementeren van een zekere interface.

okee, maar wat als je nou klassen in je collectie wil stoppen die niet van jou zijn? Dan zul je daar dus wrapper classes omheen moeten gaan maken. Vind ik persoonlijk een vervelende en omslachtige methode (die ook nog eens voor overhead zorgt, maar of dat wat uitmaakt hangt natuurlijk maar net af van wat voor applicatie je aan het maken bent)

Maar jij beweert dus dat veel C++ developers veel templatecode gewoon kunnen lezen?

Uiteraard kan ik dat niet beweren aangezien ik niet veel C++ developers ken. Maar ik kan het lezen, en ik weet van een aantal mensen dat zij het ook kunnen.

Ik denk dat maar een fractie de complete STL code begrijpt, om maar iets te noemen.

De STL is ook gewoon een vieze implementatie met allemaal gore variabele- en functienamen, om het zo maar even bot te stellen . Ik ben dan ook zeker niet pro-STL, hoewel de functionaliteit ervan erg handig is

[Anoniem: 29256]

Op dinsdag 02 juli 2002 18:28 schreef Otis het volgende:
De 'functionaliteit' die generics brengt is best handig. Hoe het in C++ is geimplementeerd vind ik niet werkbaar, tenminste wanneer je er stevig gebruik van gaat maken.

Ik kan me hier niks bij voorstellen, kun je een voorbeeld geven? Verder: C# gaat waarschijnlijk ook generics krijgen, wat vind je daarvan? (Weet iemand of daar een vernieuwende syntax voor komt?)

Toegegeven, collections van 'Object' objects, zijn niet zo bar compiletime-typesafe

Afgezien van de problemen die .oisyn noemt vind ik die type-unsafety toch wel een flink nadeel. Dan heb ik toch 10x liever een generic typesafe container waar ik zonder te casten m'n oorspronkelijke objectjes uit kan vissen.

Maar jij beweert dus dat veel C++ developers veel templatecode gewoon kunnen lezen?

Serieuze C++ developers horen imho absoluut template code te kunnen lezen. Overigens ben ik van mening dat veel te veel mensen C++ programmeren; ik heb vaak het gevoel dat C++ voor 90% van de C++ programmeurs te geavanceerd speelgoed is. (Eigenlijk heb ik vaak het gevoel dat 90% van de software-developers geen software-developer zou moeten zijn.. )

Ik denk dat maar een fractie de complete STL code begrijpt, om maar iets te noemen.

Er is niet zoiets als 'de STL code', alleen de interface en nog wat andere eisen zijn in de standaard gespecificeerd. Verder is de STL prima te begrijpen hoor, kwestie van goede documentatie kopen.

[Anoniem: 29256]

Op dinsdag 02 juli 2002 18:28 schreef Otis het volgende:
de developer van Unreal, Tim Sweeney zegt hetzelfde

Ik heb medelijden met z'n devteam .

[mbravenboer]

Otis: Wat is je punt? Dat templates nodig zijn? Waarom mist niemand ze in C# of Java?

Ik mis geen templates, maar wel hetgene wat je met templates kan bereiken. Geparameterizeerde typen zoals deze geintroduceerd worden in Java en C# compenseren naar mijn mening wel degelijk een groot gebrek in het type-systeem en ik ben er daarom erg blij mee.

Raar, je geeft daarmee aan dat bv talen als C# nu dermate onthand zijn dat ze dat voordeel terdege missen.

C# en Java zijn wel degelijk 'onthand' zonder geparameterizeerde typen. Geparameterizeerde typen zijn een belangrijke vorm van polymorfisme (universal polymorphism, geen ad-hoc polymorphism zoals coercion en overloading) en ik ben blij dat ze nu eindelijk geintroduceerd worden in Java en C#. Als jij templates geen prettige manier van om onder andere geparameterizeerd polymorphisme te realiseren, ben ik het wel met je eens .

Verder zie ik de link tussen templates en typesafety niet echt. Zolang ik void pointers kan doorgeven aan functies in C++ is de taal niet typesafe. Of wou je beweren van wel? Voorkomen templates het doorgeven van void pointers en de type-nonsafety die eromheen hangt? Kennelijk...

Type-safety is een vervelende term. Type-safety is gedefinieerd als het garanderen dat er geen operaties worden uitgevoerd op een item van een bepaald type die niet toegestaan zijn voor dit type. Wat is een runtime gecontroleerde cast echter? Nee, dit breekt geen type-safety, maar het is wel vervelend iets. Daarom wordt er in de context van geparameterizeerde typen vooral gesproken over het vergroten van compile time type-safety.

Geparameterizeerde typen maken casts voor een groot deel overbodig, waardoor Nice ( http://nice.sourceforge.net ) bijvoorbeeld al helemaal geen casts meer kent. Elke cast die je uitvoert in je code duidt een gebrek van het type-systeem aan: jij weet dat iets van een bepaald type is, maar het type-systeem kan dit niet garanderen. Geparameterizeerde typen maaien een enorme vracht casts weg en dus zijn ze imho iets zeer goeds.

Voor meer informatie is dit legendarische stuk een absolute aanrader:

On Understanding Types, Data Abstraction, and Polymorphism

[mbravenboer]

Otis: Daarom is C# ook safer dan Java, qua type-safety.

Sorry, maar dat is onzin. Op welke manier denk je? Definieer eerst type-safety eens. Wat zijn volgens jou operaties die type-safety verbreken?

Typesafety gaat er juist om at runtime ellende te vermijden.

Uiteraard, maar het is mooi als je zo veel mogelijk problemen al kunt oplossen at compile time. Via geparameterizeerde typen kan de compiler at compile time (duh ) meer uitspraken doen over eventueel ongeldige casts. Type safety is een rare term omdat een stukje Java code nooit een operatie kan uitvoeren op een type die niet toegestaan is.

Ik merk trouwens dat er nogal wat misverstanden zijn over mijn stukje code wat ik pas liet zien, waarbij een String werd gemanipuleerd via de Unsafe klasse. Dit heeft niets met de type-safety van Java te maken. De code in achter de Unsafe klasse is geimplementeerd in native code, die natuurlijk alles met Java objecten mag doen wat hij maar wil. Dat deze techniek wordt gebruikt is misschien verachtelijk, maar het doet helemaal niets af aan de taal Java.

Hier staat een goed stuk over safety in Nice:

http://nice.sourceforge.net/safety.html

Een paar kern opmerkingen uit dit stuk:

The degree in which a language guarantees that a correct program while not fail at runtime is sometimes called static safety.

All run time crashes can be converted to run time errors, which is unarguably an improvement of the safety. This typically involves checking at run time all possibly invalid code before executing it.

So why does Java allow casts? It needs them, because its type system is too limited.

One of the limitations of Java is the absence of genericity: classes and methods cannot have type parameters. Casts are often a poor way to make up for this absence.

We considered here imperative languages. There is another important family of languages that is worth considering: functional languages. More precisely, since we are interested in static safety, statically typed functional languages, the two major ones being ML and Haskell. These languages are doing very well as far as static safety is concerned. However, they achieve this safety by enforcing a quite different programming style. This makes it difficult to compare expressiveness, and definitely compromises their chances of becoming used widely.

[mbravenboer]

Sneechy: Weet iemand of daar een vernieuwende syntax voor komt?

Het schijnt ongeveer dezelfde syntax als Java Generics te gebruiken. Zie deze website:

http://research.microsoft.com/projects/clrgen/

Generics staan beschreven in dit artikel:

http://research.microsoft.com/projects/clrgen/generics.pdf
en deze presentatie:

http://www.acm.org/sigs/sigplan/pldi/pldi2001/pldi01-presentations/DonSyme.pdf

Afgezien van de problemen die .oisyn noemt vind ik die type-unsafety toch wel een flink nadeel. Dan heb ik toch 10x liever een generic typesafe container waar ik zonder te casten m'n oorspronkelijke objectjes uit kan vissen.

Zie voor een goede uitleg van jouw (imho correcte) punt het stuk van Cardelli wat ik eerder postte.

[Soultaker]

Op dinsdag 02 juli 2002 18:15 schreef Otis het volgende:
Dit gelul ontstond toen werd beweerd dat de sterke typering van C++ een van de kenmerken was die teruggevonden werd in C#, iets dat ik dus echt niet zo zie. Niet dat C++ slecht is in dat opzicht, maar C#'s typering is onvergelijkbaar met C++'s.

Ah ok, een interpretatieverschil dus. Ik ben het wat dit betreft niet met je oneens.

Ja het standaard gelul van de C++ programmeur die vindt dat zijn taal superieur is aan andere talen 'want die kunnen veel niet'. Jouw redenatie doortrekkende, is het dus zo dat C++ een slechte keuze is, want in assembler kun je het efficienter oplossen.

Nee, de kernzin van de alinea was: "Je kunt je C++ code net zo ingewikkeld maken als je zelf wilt". Ik kan in assembly niet OO programmeren, nauwelijks gebruik maken modulaire opbouw en weinig type safety verkrijgen. Mijn punt was, dat als je C++ gebruikt, je niet van de meer geavanceerde features zoals template classes gebruik hoeft te maken.

Je kunt eigenlijk elk praktisch in Java geimplementeerde OO ontwerp vrij letterlijk omzetten naar C++ (memory management erbij en klaar). Van Java naar assembly is een heel ander verhaal.

Waar assembly andere functionaliteit biedt dan C#, biedt C++ (tot op zekere hoogte) vergelijkbare functionaliteit én extra functionaliteit. De vergelijking die ik hier maakte, is dus een hele andere.

Bijna nooit heb je ze nodig. Er is niet voor niets iets als 'smart pointers', iets dat niet eens in C++ zit als taalelement, maar wel onontbeerlijk in veel gevallen.

Wat verwacht je dan van een smart pointer dat 'n auto_ptr niet voor je doet? Zelfs als je de auto_ptr functionaliteit je niet aanstaat, bieden de door jou verafschuwde mogelijkheden voor template classes en operator overloading uitkomst: je kunt zo eenvoudig smart pointer typen maken, voor élk denkbaar type (dankzij de template class), dat zich gedraagt alsof het een gewone pointer was (en daarmee dus inwisselbaar is; dankzij operator overloading).

Veelal kiest men voor een compromis tussen snelheid en ontwikkeltijd/onderhoudbaarheid. Ook dat is 'voordeel', een kortere ontwikkeltijd en goede onderhoudbaarheid.

Helemaal mee eens, evenals het voorgaande pleidooi (dat met mijn definitie van 'beter' overeenkwam). Er zijn een heleboel factoren die een rol spelen bij het ontwikkelen van een product. Vaak is beschikbare kennis zelfs de doorslaggevende factor; als de hoofdprogrammeur C# kent en geen C++, wordt C# de taal voor het project. Meestal terecht, omdat de kosten van het leren van een andere taal, als deze beter geschikt zou zijn, misschien niet opwegen tegen de (korte termijn) baten.

Nog even over je geluidspeler:

Dit is uit de functie die een soundelement start. Die wordt aangeroepen door een scriptengine. Door de cast en inheritence is het simpel in elkaar te zetten.

Hackwerk, dus. Een mooi OO ontwerp is ook simpel, maar dan omdat het ontwerp helder is en niet omdat de code zo simpel mogelijk is. In een mooi OO ontwerp was die cast vast niet nodig geweest.

Verder zou ik je willen aanraden eens Don Box' Essential Com te lezen, als je iets tegen casts hebt hehe

Hmm, is misschien geen slecht plan. Zal de bibliotheek eens checken.

[Soultaker]

Op dinsdag 02 juli 2002 20:01 schreef mbravenboer het volgende:
Ik merk trouwens dat er nogal wat misverstanden zijn over mijn stukje code wat ik pas liet zien, waarbij een String werd gemanipuleerd via de Unsafe klasse. Dit heeft niets met de type-safety van Java te maken. De code in achter de Unsafe klasse is geimplementeerd in native code, die natuurlijk alles met Java objecten mag doen wat hij maar wil. Dat deze techniek wordt gebruikt is misschien verachtelijk, maar het doet helemaal niets af aan de taal Java.

Dat had ik heel goed begrepen. Ik wilde daarmee Otis' kritiek pareren dat je in C++ de typeinfo van een bepaalde klasse zou kunnen wijzigen, door op een obscure manier C pointers te gebruiken.

Wat betreft dat artikel over typen, abstractie en polymorphisme: dat zal ik dan maar even doornemen.

_{Waarom zijn die sites met online papers altijd zo lelijk, onpractisch, lelijk, onoverzichtelijk en lelijk?}

[mbravenboer]

Waarom zijn die sites met online papers altijd zo lelijk, onpractisch, lelijk, onoverzichtelijk en lelijk? [/

Lelijk is hij inderdaad , maar praktisch is hij wel . Als je op zoek bent naar een wetenschappelijk artikel kom je vrijwel altijd op deze site terecht. Het is een uitermate nuttige en uitgebreide collectie.

[Soultaker]

Op dinsdag 02 juli 2002 20:26 schreef mbravenboer het volgende:
Lelijk is hij inderdaad , maar praktisch is hij wel . Als je op zoek bent naar een wetenschappelijk artikel kom je vrijwel altijd op deze site terecht. Het is een uitermate nuttige en uitgebreide collectie.

Klopt, ik ben er wel eens meer langs gekomen, maar ik ergerde me nu vooral dat ik een hele tijd naar het scherm moest staren voor ik 't knopje 'download as PDF' kon vinden. Het is sowieso in het begin onduidelijk welke delen van het scherm waarvoor zijn; in 't begin heb je 't idee dat de tekst op de pagina het artikel zelf is, maar dat is niet zo.

[Anoniem: 7195]

Op dinsdag 02 juli 2002 20:12 schreef Soultaker het volgende:
[..]
Nee, de kernzin van de alinea was: "Je kunt je C++ code net zo ingewikkeld maken als je zelf wilt". Ik kan in assembly niet OO programmeren, nauwelijks gebruik maken modulaire opbouw en weinig type safety verkrijgen. Mijn punt was, dat als je C++ gebruikt, je niet van de meer geavanceerde features zoals template classes gebruik hoeft te maken.

Ik kan in C en Assembler wel OO programmeren. Raar dat jij dat niet kunt. Ja natuurlijk kun je sommige functionaliteit niet gebruiken.

Je kunt eigenlijk elk praktisch in Java geimplementeerde OO ontwerp vrij letterlijk omzetten naar C++ (memory management erbij en klaar). Van Java naar assembly is een heel ander verhaal.

Nee hoor, van java naar assembler is simpeler dan van C++ naar assembler.

Waar assembly andere functionaliteit biedt dan C#, biedt C++ (tot op zekere hoogte) vergelijkbare functionaliteit én extra functionaliteit. De vergelijking die ik hier maakte, is dus een hele andere.

Maar die extra functionaliteit is overbodig, plus MIST C++ functionaliteit die C# en java WEL hebben. Kijk eens naar managed C++ en je weet waarover ik praat.

[..]
Wat verwacht je dan van een smart pointer dat 'n auto_ptr niet voor je doet? Zelfs als je de auto_ptr functionaliteit je niet aanstaat, bieden de door jou verafschuwde mogelijkheden voor template classes en operator overloading uitkomst: je kunt zo eenvoudig smart pointer typen maken, voor élk denkbaar type (dankzij de template class), dat zich gedraagt alsof het een gewone pointer was (en daarmee dus inwisselbaar is; dankzij operator overloading).

Mja, maar dan moet ik werk doen dat ik in C# gratis bij de taal krijg, en zeker weet dat het werkt, het is nl. native. Ik zie het niet echt als toegevoegde waarde hoor, dat je in C++ zelf moet klungelen met templates om iets voor elkaar te krijgen terwijl bv C# dat zelf in zich heeft.

Nog even over je geluidspeler:
[..]

Hackwerk, dus. Een mooi OO ontwerp is ook simpel, maar dan omdat het ontwerp helder is en niet omdat de code zo simpel mogelijk is. In een mooi OO ontwerp was die cast vast niet nodig geweest.

Behoorlijk boute uitspraak na het zien van 1 regel code uit een totaal van 3486. FYMFI: het is geen hackwerk, daar de elements derived classes zijn (i.e. specialisaties!) van de base class soundelement. Soundsystem class' datastore werkt met soundelements zodat ik wanneer een nieuw type soundelement moet worden toegevoegd ik niet de datastore moet updaten. De derived classes hebben een eigen unieke methodset omdat de derived classes juist specialisaties zijn. Het starten van een mp3 is anders dan het starten van een wav, vergt bv meer parameters. Die toevoegen aan de baseclass kan dus niet, ookal omdat je dan inheritence negeert. Een cast helpt dan zeker. Met templates was je een heel end gekomen, maar de initiele call naar de unieke method per derived classtype vanuit de soundsystemclass is niet zonder cast te doen. Zie sourcecode: http://www.demogl.com/download.asp

[..]
Hmm, is misschien geen slecht plan. Zal de bibliotheek eens checken.

FYI: Dit boek staat bol van de casts. Het legt uit hoe je COM implementeert in C++ middels casts, vtable setups etc. Erg knap allemaal, maar ook niet op een andere manier te doen.

[Soultaker]

Op dinsdag 02 juli 2002 20:45 schreef Otis het volgende:
Ik kan in C en Assembler wel OO programmeren. Raar dat jij dat niet kunt. Ja natuurlijk kun je sommige functionaliteit niet gebruiken.

Dat is natuurlijk onzin. Dan komen we weer terug bij "Je kan in elke willekeurige Turing-complete taal programmeren wat je ook in een andere Turing-complete taal kunt programmeren". Je weet best wat ik bedoel.

C++ biedt veel funtionaliteit die assembly niet biedt. C# biedt vergelijkbare functionaliteit als C++. Maar dat had ik al gezegd en veel duidelijker kan ik het niet maken.

Nee hoor, van java naar assembler is simpeler dan van C++ naar assembler.

Daar heb ik het nooit over gehad en daar wil ik het ook helemaal niet over hebben. Wat doet assembler hier opeens tussendoor? Daar ging het helemaal niet over.

Maar die extra functionaliteit is overbodig, plus MIST C++ functionaliteit die C# en java WEL hebben. Kijk eens naar managed C++ en je weet waarover ik praat.

Wat is dat? Een programmeertechniek? Een boek? Misschien kun je het even kort samenvatten?

Mja, maar dan moet ik werk doen dat ik in C# gratis bij de taal krijg, en zeker weet dat het werkt, het is nl. native. Ik zie het niet echt als toegevoegde waarde hoor, dat je in C++ zelf moet klungelen met templates om iets voor elkaar te krijgen terwijl bv C# dat zelf in zich heeft.

Dan ben ik toch heel erg benieuwd (zoals ik ook al in m'n vorige post vroeg) wat voor eisen jij aan smart pointer stelt, die een (inderdaad simpele) auto_ptr niet biedt.

Daarbij is er genoeg standaard code voor smart pointer templates te vinden. Het idee van OO is dat code herbruikbaar is en dit is er een mooi voorbeeld van.

Behoorlijk boute uitspraak na het zien van 1 regel code uit een totaal van 3486. FYMFI: het is geen hackwerk

Ok, ik kan daar niet met recht over oordelen. Maar ik ga nu ook niet ten behoeve van de discussie 3486 regels code doorspitten. Als je een klassenschema of ontwerpdocument hebt, wil ik 'm nog wel even inkijken.

Als we de discussie doorzetten, wil ik trouwens wel dat je wat meer aandacht besteedt aan de inhoud van mijn reacties. Ik heb nu het idee dat ik dezelfde dingen herhaal, terwijl ik volgens mij toch wel duidelijk ben. Een beetje je best doen om m'n punt te begrijpen kan geen kwaad.

[Anoniem: 7195]

Op dinsdag 02 juli 2002 19:25 schreef Sneechy het volgende:
[..]
Ik kan me hier niks bij voorstellen, kun je een voorbeeld geven? Verder: C# gaat waarschijnlijk ook generics krijgen, wat vind je daarvan? (Weet iemand of daar een vernieuwende syntax voor komt?)

Werp eens een blik in de STL zou'k zeggen. En nog iemand die niet snapt dat als je de syntaxis van templates verschrikkelijk vindt, dat niet betekent dat je de functionaliteit ook verschrikkelijk vindt. C++ is IMHO echt in veel gevallen een over het paard getilde taal, omdat de syntax dermate complex is terwijl dat niet HOEFT. De door bravenboer aangehaalde links laten voorbeelden zien van syntaxis die simpeler is, en je zou met wat nadenken op nog simpelere syntaxis kunnen komen, immers wat je wilt is niets anders dan de C# equivalent van bv een collection van 'Object' objects maar dan met typesafety, dus per type.

[..]
Afgezien van de problemen die .oisyn noemt vind ik die type-unsafety toch wel een flink nadeel. Dan heb ik toch 10x liever een generic typesafe container waar ik zonder te casten m'n oorspronkelijke objectjes uit kan vissen.

Mja, vind ik een vreemde redenatie. Hoe bewijs jij nl. dat je template correct is? Bij een nested template-tree wordt dat al erg lastig, zonder het geheel eens uit te gaan schrijven. Ergo: je maakt daar snel bugs mee, iets wat je at runtime ook tegenkomt bij collections van 'object' objects die je verkeerd cast en door de CLR worden afgevangen en worden getoond door een foutmelding.

[..]
Serieuze C++ developers horen imho absoluut template code te kunnen lezen. Overigens ben ik van mening dat veel te veel mensen C++ programmeren; ik heb vaak het gevoel dat C++ voor 90% van de C++ programmeurs te geavanceerd speelgoed is. (Eigenlijk heb ik vaak het gevoel dat 90% van de software-developers geen software-developer zou moeten zijn.. )

Een taal is een hulpmiddel bij het verwoorden van functionaliteit voor de CPU. ALLE hulp daarbij is welkom. Niemand heeft er wat aan als de taal die gebruikt wordt, sneller fouten veroorzaakt, moeilijker te onderhouden is etc. Het gaat er nl. om dat je de functionaliteit verwoord die gerealiseerd moet worden. Welke taal je daarvoor kiest is inherent aan de te realiseren functionaliteit, NIET aan de te korte penis van een omhooggevallen C++ klopper, die status denkt te ontlenen aan zijn grote kennis van een enkele programmeertaal. Ik vind inzicht in hoe software het meest efficient gebouwd en onderhouden kan worden vele malen belangrijker dan de indepth kennis van een enkele taal. Immers: het team dat in de kortst mogelijke tijd de meeste functionaliteit op een betrouwbare en onderhoudbare manier bouwt is voor klant EN bouwer efficienter bezig. Kies je voor een taal waarbij je veel zelf moet doen, dus veel fouten kunt maken, wat het traject er niet betrouwbaarder, korter en dus efficienter op maakt, met een complexe syntaxis, waarbij de gemiddelde programmeur niet 100% van begrijpt, dus onderhoudbaarheid ondermijnd, dan ben je in veel gevallen dom bezig, tenzij er geen alternatief is. Voor veel applicaties die in opdracht van bedrijven worden gebouwd, zijn er alternatieven zat.

DAT is belangrijk bij softwaredevelopment. Het tot in de puntjes leren van een C++ syntaxis echter niet, immers er zijn alternatieven waarbij met minder moeite wel complexe functionaliteit in gebouwd kan worden, bv C# of Java. Ben je dan een unter-programmeur, minderwaardig tov de C++ programmeur die alle ins/outs van C++ kent? IMHO niet. De persoon die spullen produceert die voor anderen makkelijk te begrijpen zijn en te onderhouden zijn, solide zijn omdat de taal/tool die eigenschappen biedt, DAT is de software engineer die je wilt.

[..]
Er is niet zoiets als 'de STL code', alleen de interface en nog wat andere eisen zijn in de standaard gespecificeerd. Verder is de STL prima te begrijpen hoor, kwestie van goede documentatie kopen.

Er zijn maar een paar volledig werkende implementaties beschikbaar, dus je komt vrij snel uit dezelfde implementatie. Semantisch de functionaliteit doorlopen is goed te doen ja. Maar als iemand at random een paar regels weghaalt uit een sourcefile, kun jij die dan zo herstellen? ERG veel mensen niet, ookal denken ze C++ te begrijpen.

Als ik at random regels weghaal uit de in C# geschreven .NET api van Rotor lukt het veel meer mensen, daar ben ik van overtuigd.

[Anoniem: 7195]

Op dinsdag 02 juli 2002 20:56 schreef Soultaker het volgende:
[..]
Dat is natuurlijk onzin. Dan komen we weer terug bij "Je kan in elke willekeurige Turing-complete taal programmeren wat je ook in een andere Turing-complete taal kunt programmeren". Je weet best wat ik bedoel.

ja dat weet ik best, maar jij zei dat C++ beter was omdat je daar dingen veel efficienter in kon oplossen. In Assembler kan dat nog efficienter. Ergo: er is een afweging te maken tussen efficiency enerzijds en abstractieniveau anderszijds. In C++ ligt die erg bij efficiency, in C# ligt die meer bij abstractieniveau. Het is maar net wat je prefereert: veel code schrijven om die spaarzame cycles te besparen op je Athlon XP 2200+, of veel minder code schrijven maar een paar cycles inleveren.

C++ biedt veel funtionaliteit die assembly niet biedt. C# biedt vergelijkbare functionaliteit als C++. Maar dat had ik al gezegd en veel duidelijker kan ik het niet maken.

C# biedt een veel abstractere kijk op software development, C++ daarentegen zit daar ver onder. Veel syntaxconstructies zijn wellicht identiek, maar het gaat juist om de zaken als GC, type safe objectreferences, alles heeft dezelfde baseclass, transparante integratie met binary objectmodels als COM, indexers, attributed programming. C++ mist dat allemaal, doordat de afweging is gemaakt dat efficiency kennelijk belangrijker was dan abstractie. C'est la vie, maar als je dat als 'beter' definieert, kun je alleen maar van 'veel tikwerk' houden en veel bugs die daar inherent aan zijn. Als je geen keus hebt, zoals in de embedded wereld, ala. Als je wel de keus hebt, zoals in de meeste gevallen, dan denk ik: waarom moeilijk doen?

[..]
Daar heb ik het nooit over gehad en daar wil ik het ook helemaal niet over hebben. Wat doet assembler hier opeens tussendoor? Daar ging het helemaal niet over.

zie boven.

[..]
Wat is dat? Een programmeertechniek? Een boek? Misschien kun je het even kort samenvatten?

Managed C++ is de verkrachting van C++ door Microsoft (niet mijn woorden ) door een subset van C++ te nemen zodat het met .NET kan samenwerken (wat bv single inheritence heeft en garbage collection). Je moet extensies gebruiken van de taal voor de GC en andere ongein om dezelfde functionaliteit te halen als C# voor hetzelfde platform. Niet echt te prefereren dus.

[..]
Dan ben ik toch heel erg benieuwd (zoals ik ook al in m'n vorige post vroeg) wat voor eisen jij aan smart pointer stelt, die een (inderdaad simpele) auto_ptr niet biedt.

auto_ptr is een subset van een smart pointer imho, een smart pointer moet ook COM crap in zich hebben, dus refcounts, interface querying, etc. De VC++ smart pointers voor COM zijn een mooi voorbeeld daarvan: je hebt weinig last van de COM overhead die nodig is voor het gebruik van COM objects in C++.

Daarbij is er genoeg standaard code voor smart pointer templates te vinden. Het idee van OO is dat code herbruikbaar is en dit is er een mooi voorbeeld van.

Mja, als ik zeg dat ik in VB of C# dezelfde functionaliteit terugvindt, maar dan zonder smartpointergeneuzel, vind ik C++ tekortschieten in dat opzicht: voor de developer is het nl. onzichtbaar, het wordt geregeld. In C++ moetje het zelf regelen. Win je daar wat mee? Nee, in het geheel niet. Je verliest er alleen maar mee, want je moet toch die smartpointers toevoegen aan je code en de syntaxis is niet zo smooth als bv in C#.

In dat opzicht zeg ik: C# heeft echt dingen verbeterd die in C++ rampzalig zijn geregeld. In C++ kun je het wel oplossen, maar in C# zit dat al bij de taal. Dat is het verschil hier.

[..]
Ok, ik kan daar niet met recht over oordelen. Maar ik ga nu ook niet ten behoeve van de discussie 3486 regels code doorspitten. Als je een klassenschema of ontwerpdocument hebt, wil ik 'm nog wel even inkijken.

Zeg, ik ga van hobbyprojects geen design documents maken hoor, althans niet die ik tot in lengte van dagen bewaar

[Anoniem: 29256]

Op dinsdag 02 juli 2002 21:08 schreef Otis het volgende:
De door bravenboer aangehaalde links laten voorbeelden zien van syntaxis die simpeler is

Ik zie op het eerste gezicht eigenlijk nouwelijks verschil tussen die C# generics syntax en de C++ templates. Het scheelt een keywordje, meer niet.

immers wat je wilt is niets anders dan de C# equivalent van bv een collection van 'Object' objects maar dan met typesafety, dus per type.

Ik vind deze vergelijking erg scheef. Ik zie niet hoe je het parameterizeren van een type kunt vergelijken met het gebruik van een universele root-class..

Oh en templates zijn voor veel meer geschikt hoor .

Hoe bewijs jij nl. dat je template correct is?

Ik denk m'n code uit, schrijf 'm op, test 'm, klaar. Bewijs?

Ergo: je maakt daar snel bugs mee

Wat voor bugs heb je het over

Maar als iemand at random een paar regels weghaalt uit een sourcefile, kun jij die dan zo herstellen? ERG veel mensen niet, ookal denken ze C++ te begrijpen.

Dat is die 90% waar ik het al eerder over had . Lekkere maatstaven heb jij trouwens, at random regels weghalen en vervolgens verwachten dat men ze maar even moet kunnen herschrijven .

Edit: Speciaal voor jouw komen er trouwens hoogstwaarschijnlijk weer een aantal nieuwe smart pointers in de C++0x standaard .

[Anoniem: 7195]

Op dinsdag 02 juli 2002 20:07 schreef mbravenboer het volgende:
[..]
Het schijnt ongeveer dezelfde syntax als Java Generics te gebruiken.

Wat ik begrijp van de Sun Java generics is dat ze NIET worden doorgevoerd op het JVM level, maar volledig uitgecompileerd worden? (Iets dat bij de CLR niet gebeurt)

[Anoniem: 7195]

Op dinsdag 02 juli 2002 22:17 schreef Sneechy het volgende:
[..]
Ik zie op het eerste gezicht eigenlijk nouwelijks verschil tussen die C# generics syntax en de C++ templates. Het scheelt een keywordje, meer niet.

Nee er is wel degelijk veel verschil. Ja, de '<' en '>' zijn er, maar imho is een getemplatiseerde class in C++ complexer en dus moeilijker te lezen dan een generic typed class in C#.

[..]
Ik vind deze vergelijking erg scheef. Ik zie niet hoe je het parameterizeren van een type kunt vergelijken met het gebruik van een universele root-class..

Het parametriseren van een type gebruik je om het type te gebruiken met een veelvoud van andere typen. Dmv de baseclass 'Object' kun je dat ook nu al, zonder templates, in C# met daarbij casts. De functionaliteit is hetzelfde: het type kan omgaan met alle typen in de CLR, standaard en user-defined.

Oh en templates zijn voor veel meer geschikt hoor .

ja, wat dacht je waar die hekel aan templates vandaan kwam. Niet van een algemene CArray<> class die handig is in C++.

[..]
Ik denk m'n code uit, schrijf 'm op, test 'm, klaar. Bewijs?

Vooral bij nested templates wordt het al snel een probleem. Code die zonder parameters is opgeschreven is dan makkelijker te doorgronden.

[..]
Wat voor bugs heb je het over

Ik heb hier eens een thread gezien van iemand die een serie nested templates niet aan de gang kreeg. Geweldig voorbeeld wat voor verschrikkelijke crap je ermee kunt maken, en dat is al vrij snel als je je niet op de vlakte houdt met geparametriseerde typen.

[..]
Dat is die 90% waar ik het al eerder over had . Lekkere maatstaven heb jij trouwens, at random regels weghalen en vervolgens verwachten dat men ze maar even moet kunnen herschrijven .

Als je de code kunt doorgronden is dat vrij simpel. Een lukraak gekozen STL is echter niet zo simpel te doorgronden. Toch willen sommige mensen per se moeilijke syntax gebruiken en lastig te lezen code produceren. Bizarre instelling.

Edit: Speciaal voor jouw komen er trouwens hoogstwaarschijnlijk weer een aantal nieuwe smart pointers in de C++0x standaard .

Weet ik. Is wel veel te laat, en imho een teken aan de wand dat Straustrupp het echt over het hoofd heeft gezien bij het ontwerpen van de taal.

[curry684]

Op dinsdag 02 juli 2002 12:18 schreef elnino het volgende:
Microsoft heeft C# ontworpen om een betere versie van C++ te maken. Daarom noem ik het nu ook even 'verbeterd'.

Je insteek is fout: Microsoft heeft C# ontworpen omdat Java van Sun is. De grondbeginselen zijn hetzelfde, de meeste grammatica ook, maar C# mogen ze nu alles aan vermeubelen zoals ze met een hoop andere dingen ook al hebben gedaan (iemand zich ook al eens lopen verbazen over die 'MFC Compatibility Mode'-checkbox in C++Builder? )

C# heeft net zoveel met C++ van doen als een bakker met een astronaut.

Begrijp me niet verkeerd, ik vind C# een leuke taal en er zit veel potentie in. Maar het is en blijft een Java-ripoff.

[mbravenboer]

Otis: Wat ik begrijp van de Sun Java generics is dat ze NIET worden doorgevoerd op het JVM level, maar volledig uitgecompileerd worden? (Iets dat bij de CLR niet gebeurt)

Ja, dat klopt ongeveer, maar dit betekent niet dat de JVM geen kennis heeft van Java Generics. Er zijn bijvoorbeeld wel mogelijkheden om via reflectie te onderzoeken wat voor parameters een klasse heeft.

De instructie-set zal voor zover ik weet niet worden aangepast en je kan at runtime geen informatie krijgen over de parameters van een instantie van een geparameterizeerde klassen. Dat is best wel vervelend. Voor deze aanpak is bewust gekozen ivm de , maar dan neemt niet weg dat ik het een vervelende keuze vindt.

NextGen is een uitbreiding van deze ideeen, wat meer op 1 lijn ligt met de .NET Generics. Het schijnt dat ze van plan zijn om de huidige oplossing (geplanned voor 1.5) later verder uit te breiden naar een NextGen achtige oplossing met meer runtime mogelijkheden.

Je vindt de reden van de huidige 'mindere' oplossing terug in de doelstellingen:

C1) Upward compatibility with existing code. Pre-existing code must work on the new system. This implies not only upward compatibility of the class file format, but also interoperability of old applications with parameterized versions of pre-existing libraries, in particular those used in the platform library and in standard extensions.

C2) Upward source compatibility. It should be possible to compile essentially all existing
Java language programs with the new system.

Dit is echter expliciet geen doel:

a) Provide downward binary compatibility: It is not necessary that class files compiled under the generic compiler should run on previous releases, whether they
use generics or not.

Zie voor NextGen dit artikel:
Compatible Genericity with Run-time Types for the Java Programming Language (ook weer een erg leuk stuk ).

Persoonlijk ben ik een groot voorstander van een krachtigere aanpak, waarbij er minder gelet wordt op legacy code, maar ja: die heb ik zelf niet zo veel .

[mbravenboer]

Otis: Het parametriseren van een type gebruik je om het type te gebruiken met een veelvoud van andere typen. Dmv de baseclass 'Object' kun je dat ook nu al, zonder templates, in C# met daarbij casts. De functionaliteit is hetzelfde: het type kan omgaan met alle typen in de CLR, standaard en user-defined.

Ik quote even het NextGen artikel en trap daarbij een open deur in die je zelf uiteraard al open zag gaan:

In our experience, the most serious impediment to writing substantial programs in Java is the lack of a mechanism for abstracting classes and methods with respect to type. Type parameterization can be simulated in Java by using the universal reference type Object in place of type parameters and explicitly casting values of type Object to their intended types. But this coding idiom is clumsy and error prone because the required casts are tedious to write and largely defeat the error-detection properties of Java's static typing discipline.

[mbravenboer]

Hier staat trouwens waarom er niet nu al voor de NextGen implementatie is gekozen:

NextGen differs from GJ in that instances of parametric classes are not instances of the base class. In essence, new data is distinct from old data. In general, new data can be used in place of old data, but not vice versa. Hence, programs that intermix old and new data must explicitly convert old data to the new form. The parametric generalization of java.util could include parameterized methods that perform these conversions.

In general, mixed programming involving both old and new data is poor software engineering practice. Old code should be revised to use parametric types.

Dat vind ik nou ook .

But when source for old code is unavailable, "mixed data" programming may be unavoidable. The ability to mix old and new code also provides a smooth transition path during code conversion. NextGen, following in the footsteps of GJ, supports such mixed programming. NextGen, however, generally requires more "glue code" between new code and old code than GJ does.

Das de reden dus.

Precies vanwege al deze problemen vond ik het erg jammer dat .NET niet gelijk generics ondersteunde en ik vind het dapper dat ze het nu toch zo grondig aanpakken. Helaas vertellen ze in de presentaties meestal wel dat ze een betere oplossing hebben dan Java Generics, maar vergeten ze daarbij de gevolgen te vermelden voor 'legacy C# code' ( ). Ik heb nog nergens kunnen lezen hoe ze met deze gevolgen omgaan (iemand anders wel?). Ik ken de implementatie overigens niet goed genoeg om deze gevolgen goed te overzien en heb uiteraard ook nog niet met een implementatie kunnen spelen.

[.oisyn]

^psssst,

[mbravenboer]

.oisyn: psssst

Dan leest niemand het meer omdat het te lang is .

Bovendien scoor ik graag nog wat tech-posts: ik wil dolgraag de HK in .

[Anoniem: 7195]

Op dinsdag 02 juli 2002 23:09 schreef mbravenboer het volgende:

[..]

Ik quote even het NextGen artikel en trap daarbij een open deur in die je zelf uiteraard al open zag gaan:
[..]

Ik zei ook niet dat ik het een geweldige oplossing vond alleen dat het nu al kan. Je kunt verder middels het keyword 'is' in C# gewoon testen op een type at runtime, als je per se wilt voorkomen dat je een IllegalCastException krijgt.

Overigens is het ook nog zo dat de .NET api veel classes bevat die de noodzaak voor geparametriseerde types verkleint. Veel template toepassingen in C++ zijn al geimplementeerd in de .NET api.

[Anoniem: 7195]

Op dinsdag 02 juli 2002 23:25 schreef mbravenboer het volgende:
Precies vanwege al deze problemen vond ik het erg jammer dat .NET niet gelijk generics ondersteunde en ik vind het dapper dat ze het nu toch zo grondig aanpakken. Helaas vertellen ze in de presentaties meestal wel dat ze een betere oplossing hebben dan Java Generics, maar vergeten ze daarbij de gevolgen te vermelden voor 'legacy C# code' ( ). Ik heb nog nergens kunnen lezen hoe ze met deze gevolgen omgaan (iemand anders wel?). Ik ken de implementatie overigens niet goed genoeg om deze gevolgen goed te overzien en heb uiteraard ook nog niet met een implementatie kunnen spelen.

Die generics.pdf op de MS research page (jij hebt een link gegeven gister) zegt juist dat de generics implementatie in de CLR een extensie is, niet een substitutie en de compilers kunnen worden uitgebreid met support voor deze feature, niet dat ze moeten worden herschreven. De IL instructieset wordt dan ook uitgebreid, dus legacy code werkt gewoon door, nieuwe code kan met geparametriseerde typen werken. Omdat alles werkt met interfaces, en je die niet wijzigt, zal legacy code in de toekomst met de non-parametriseerde code kunnen blijven werken. Nieuwe code met geparametriseerde typen zal niet worden gebruikt door legacy code.

De .NET api zal wel voor een deel moeten worden aangepast, maar je kunt de interfaces niet wijzigen (kan wel, maar is erg dom) , dus zullen er extra classes komen, en niet dat er classes worden vervangen. De Collection classes bv werken nu met 'Object' en zullen dan zeker een geparametriseerde variant als buurman krijgen.

[mbravenboer]

Otis: niet dat ze moeten worden herschreven.

Uiteraard kan je gewoon met de gemeenschappelijke superklasse blijven werken, dus bestaande compilers hoeven inderdaad alleen maar te worden uitgebreid met nieuwe constructies. Het is echter nog maar de vraag wat ze met libraries zullen doen. Het gaat bij generics namelijk niet bepaald om de instructie-set, maar juist om de code die tegen niet geparameterizeerde libraries aanpraten die je nu juist geparameterizeerd zou willen implementeren.

Omdat alles werkt met interfaces, en je die niet wijzigt, zal legacy code in de toekomst met de non-parametriseerde code kunnen blijven werken.

Het lijkt mij uitermate onwenselijk om de interface niet te wijzigen. Je krijgt zo code die op het ene type werkt en code die op de andere werkt. Dit juist precies de onaantrekkelijke mix waar ze het in het NextGen stuk over hebben. Je zult conversie-slagen moeten maken tussen beide takken met alle vervelende problemen daarbij.

De .NET api zal wel voor een deel moeten worden aangepast, maar je kunt de interfaces niet wijzigen (kan wel, maar is erg dom), dus zullen er extra classes komen, en niet dat er classes worden vervangen.

Dat lijkt mij pas een zeer onaantrekkelijke situatie. Zo krijg je twee 'branches' van klasse-structuren die beide apart onderhouden moeten worden. In de Java API worden deze klassen wel gewoon geparameterizeerd, maar mogen ze ook ongeparameterizeerd gebruikt worden. Ze noemen dat 'raw' types.

De Collection classes bv werken nu met 'Object' en zullen dan zeker een geparametriseerde variant als buurman krijgen.

Dat lijkt mij dus echt verschrikkelijk en ik hoop ook niet dat ze dat gaan doen. Zo heb ik het ook absoluut niet begrepen. Als dit wel zou gebeuren, zou dat een heel goed bewijs zijn van mijn commentaar op de latere invoering van Generics.

Ik hoop dat ze het een stuk drastischer aanpakken en de relatieve jongheid van het platform benutten om het goed te doen. Geen halfzachte oplossingen die je de rest van de jaren met je meesleept. Tools kunnen eventueel een conversie ondersteunen.

[mbravenboer]

Otis: Je kunt verder middels het keyword 'is' in C# gewoon testen op een type at runtime, als je per se wilt voorkomen dat je een IllegalCastException krijgt.

Of je een illegal cast nu opvangt met een if statement of opvangt via een exception, maakt niet zoveel uit: het is en blijft een cast en zoals ik net al zei duidt elke cast op een zwakte in het type-systeem.

[Anoniem: 7195]

Op woensdag 03 juli 2002 09:42 schreef mbravenboer het volgende:

[..]

Of je een illegal cast nu opvangt met een if statement of opvangt via een exception, maakt niet zoveel uit: het is en blijft een cast en zoals ik net al zei duidt elke cast op een zwakte in het type-systeem.

Een exception die in de catch() terecht komt is niet terug te dirigeren naar de regel waar de exception optrad. Door een if() kun je opvangen dat je een illegal cast doet en bv een ander codepath bewandelen.

Ik zie casts niet als een hiaat in het type-systeem, maar noodzakelijkheden om van het ene type naar het andere te komen. OO talen hebben nu eenmaal de zaligheid dat je via de baseclass van een serie typen, code kunt schrijven die met al die typen werkt, bv een datastructuur. Het enige dat daaraan ontbreekt is typering tijdens compiletime. Middels generics kun je dat realiseren. Nu krijg ik wel een beetje een misselijk gevoel in de maag als ik mensen zie kermen dat een taal zonder generics rampzalig is, terwijl men zelf werkt met pointers naar memory en waarbij code als dit:

code:

CMyClass mcFoo;
unsigned char *pBar;

pBar=(unsigned char*)mcFoo;
*pBar=NULL;

mogelijk is. Ik vind het een beetje zeuren, ERG zeuren eerlijk gezegd. Generics zijn een hele leuke functionaliteit en het _ENIGE_ waar ze van nut zijn is code-reuse, dus universialiteit bewerkstelligen in datastructuren en code. Als je dat niet nodig hebt, want je werkt met een beperkte set known objects die een voorgedefinieerde interface implementeren, heb je generics niet nodig.

Ik zie ze dan ook als aanvulling op een taal, en voornamelijk voor universele API bouwers, bv de .NET api. Voor software engineers, die in feite veelal API consumers zijn, heb je genoeg aan wat er nu al wordt geboden, wellicht in sommige gevallen niet, maar je kunt nu al middels bv interfaces code reuse bewerkstellingen binnen bv C# binnen bv datastructuren, en dat zonder type-checking compromissen.

[OMX2000]

heeft iemand al ervaring met dynamic typed programmeer talen zoals Smalltalk. Ik vond het een beetje jammer dat MS daar niet voor gekozen heeft in .Net.

[Anoniem: 7195]

Op woensdag 03 juli 2002 09:39 schreef mbravenboer het volgende:
[..]
Uiteraard kan je gewoon met de gemeenschappelijke superklasse blijven werken, dus bestaande compilers hoeven inderdaad alleen maar te worden uitgebreid met nieuwe constructies. Het is echter nog maar de vraag wat ze met libraries zullen doen. Het gaat bij generics namelijk niet bepaald om de instructie-set, maar juist om de code die tegen niet geparameterizeerde libraries aanpraten die je nu juist geparameterizeerd zou willen implementeren.

Mja, maar het mooie aan interfaces is juist dat je een nieuwe kunt definieren en die door andere classes kunt laten implementeren zodat je een oudere in tact houdt. Ik zie het nut totaal niet van het herschrijven van de huidige .net api omwille van generics, WEL zie ik het nut van het UITBREIDEN van de api omwille vn generics. En dat is ook logisch, het interface systeem vraagt daarom, zodat huidige code kan blijven bestaan en nieuwe code de generics kan gebruiken, PLUS dat mensen die geen generics nodig hebben, ze ook niet hoeven te gebruiken.

[..]
Het lijkt mij uitermate onwenselijk om de interface niet te wijzigen. Je krijgt zo code die op het ene type werkt en code die op de andere werkt. Dit juist precies de onaantrekkelijke mix waar ze het in het NextGen stuk over hebben. Je zult conversie-slagen moeten maken tussen beide takken met alle vervelende problemen daarbij.

Welnee. Je wijzigt geen interfaces van een API. Dat staat gelijk aan het killen van een api, want ieder programma zal niet meer werken met de api, developers vinden dat niet fijn en dat is meer dan terecht, en het is ook ONNODIG om interfaces te wijzigen: je definieert gewoon een nieuwe. Wellicht implementeren de classes van de .NET api met generics dezelfde interfaces van de 1e release PLUS de interfaces met generics. Net als in COM.

Ik zou het zeer onwenselijk vinden om al mn code om te moeten schrijven voor generics, terwijl ik ze niet gebruik en het nu ook goed werkt: veel werk doen om niks: het voegt niets toe aan de huidige code en het is onnodig omdat je interfaces hebt.

Ik snap best dat code als:

code:

ArrayList myArrayList = new ArrayList();

met generics gelijk staat aan:

code:

ArrayList<Object> myArrayList = new ArrayList<Object>();

Maar, waarom moet men dat omschrijven? Ik zie het meer als: het werkt nu met object, als je generics wilt gebruiken, dan gebruik je de updated classes maar. Legacy code blijft doordraaien en de nieuwe code ook. Iedereen blij. Ik denk dat ze overigens, dat bedenk ik me nu, wellicht de huidige implementatie onder water vertalen naar een generic implementatie (wat ik wel ranzig zou vinden, ivm debugger-ellende). Maar interfaces wijzigen lijkt me uit den boze.

[Otis: De .NET api zal wel voor een deel moeten worden aangepast, maar je kunt de interfaces niet wijzigen (kan wel, maar is erg dom), dus zullen er extra classes komen, en niet dat er classes worden vervangen.]
Dat lijkt mij pas een zeer onaantrekkelijke situatie. Zo krijg je twee 'branches' van klasse-structuren die beide apart onderhouden moeten worden. In de Java API worden deze klassen wel gewoon geparameterizeerd, maar mogen ze ook ongeparameterizeerd gebruikt worden. Ze noemen dat 'raw' types.

Ik denk dat de classes dmv het implementeren van de nieuwe interfaces dit ook in .NET gaan doen, maar het is koffiedik kijken. Wat de IL betreft is het simpel: gewoon uitbreiden van wat er nu is. Dit doe je normaliter dmv een nieuwe interface die je toevoegt aan de implementatie van een class.

[Otis: De Collection classes bv werken nu met 'Object' en zullen dan zeker een geparametriseerde variant als buurman krijgen.]
Dat lijkt mij dus echt verschrikkelijk en ik hoop ook niet dat ze dat gaan doen. Zo heb ik het ook absoluut niet begrepen. Als dit wel zou gebeuren, zou dat een heel goed bewijs zijn van mijn commentaar op de latere invoering van Generics.

Dubbele classes is inderdaad wat overbodig, omdat je interfaces hebt, dus ik denk meer aan 1 class die zich voordoet als 2 verschillende, middels de verschillende interfaces. Dit zullen ze toch moeten doen ivm de dictionaries die ze willen doorgeven aan parametriseerde methods mbt types. (OF ze gaan voor onderwater compilatie van bestaande code naar <Object> parametriseerde varianten)

Ik hoop dat ze het een stuk drastischer aanpakken en de relatieve jongheid van het platform benutten om het goed te doen. Geen halfzachte oplossingen die je de rest van de jaren met je meesleept. Tools kunnen eventueel een conversie ondersteunen.

Ik zou het werkelijk een schop in mn tanden vinden als ze alles parametriseert maken en maar middels 'tools' de handel moet converteren. Het is bij microsoft al heel erg lang doorgedrongen dat zodra je 1 interface released, je daaraan vast zit. Ze hebben bewust gekozen voor deze interface, dus kunnen ze niet terug. En ik denk dat dat ook niet nodig is: je definieert nieuwe interfaces en die implementeer je ook, naast de oude. Oude code of nieuwe code die geen parametriseerde code wil gebruiken, kan de non-parametetriseerde versie gebruiken, de andere gebruikt de parametriseerde versie. Op zich is de geparametriseerde versie niet echt trager, maar voor simpelheid lijkt het me logisch dat als je het niet nodig hebt, je het ook niet moet (hoeven) gebruiken .

[Anoniem: 55933]

Op dinsdag 02 juli 2002 00:28 schreef mbravenboer het volgende:

(Topicstarter wilt C# niet gebruiken omdat ie van MS is)

Dat lijkt mij een weinig zinvolle reden in ieder geval...

Mij wel, programmeertalen van MS zijn hoogstwaarschijnlijk niet portable en compatible met andere besturingssystemen.

[mbravenboer]

Otis: Een exception die in de catch() terecht komt is niet terug te dirigeren naar de regel waar de exception optrad. Door een if() kun je opvangen dat je een illegal cast doet en bv een ander codepath bewandelen.

Met een if beloop je ook een ander codepath.

Ik zie casts niet als een hiaat in het type-systeem

Tja, het is je vast duidelijk dat ik dat wel vind .

maar noodzakelijkheden om van het ene type naar het andere te komen.

Nee: een cast zet iets niet om van het ene type naar het andere. Een object is van een bepaald type en een cast veranderd daar helemaal niets aan (behandel casts van primitieven even apart want dat zijn in feite expliciete conversies).

Een cast is een 'hack' in je code om een instantie van een bepaalde klasse te gebruiken als een specifieker type. Deze cast is mogelijk omdat jij weet dat het object van dit specifiekere type is, maar het type-systeem dit niet zelf kan afleiden en daarom een expliciete cast wil zien.

Als het type-systeem zelf had kunnen afleiden dat het object van dit specifiekere type is, was de cast niet nodig geweest. Vandaar dat iets als een cast bijvoorbeeld helemaal niet bestaat in hogere orde functionele talen. Het type systeem is daar zo krachtig dat casts absoluut overbodig zijn.

ERG zeuren eerlijk gezegd. Generics zijn een hele leuke functionaliteit en het _ENIGE_ waar ze van nut zijn is code-reuse, dus universialiteit bewerkstelligen in datastructuren en code.

Tuurlijk: alle vormen van polymorphisme hebben alleen maar unversaliteit van code tot deel. Dit kan je reuse noemen, maar ik noem het liever grote mogelijkheid tot het implementeren van generieke oplossingen. Deze generieke oplossingen kan je inderdaad hergebruiken.

maar je kunt nu al middels bv interfaces code reuse bewerkstellingen binnen bv C# binnen bv datastructuren, en dat zonder type-checking compromissen.

Sorry, maar dat is echt onzinnig. Generics zorgen er juist voor dat je code kunt parameterizeren met typen. Dit zorgt voor een generieke implementatie (universele quantificatie) van een stuk code over een verzameling typen. Generics zorgen hierdoor juist voor een betere statische type-checking dan met het werken met een unvirsele superklasse als Object.

Neem bijvoorbeeld eens een sorteer algoritme:

code:

public List sort(List list)

Er is geen enkele garantie dat de typen van de items in de list hetzelfde blijft tijdens het sorteren. Dit verwacht je uiteraard wel, maar het is niet gedocumenteerd in de code zelf en de compileer kan er absoluut geen uitspraak over doen.

Als je een item uit de List wilt halen zal je een cast moet doen, wat dus een hack in het type-systeem is.

Als je echter dit bekijkt:

code:

public <T> List<T> sort(List<T> list)

Heb je at compile time een stuk meer duidelijkheid, om het nog maar geeneens te hebben over de documenterende waarde. Dit signatuur geeft aan dat deze methode voor alle typen T (universele quantificatie) een sorteer methode implementeert die als parameter een List of Ts neemt en een List of Ts oplevert. Daar kan je iets mee: een cast is niet meer nodig omdat het type systeem zelf kan garanderen dat een object van type T is als je het uit de List haalt.

Ik zou eens dat stuk van Cardelli doorlezen, want dat is echt heel erg interessant en duidelijk geschreven. Zodra het over polymorphisme gaat wordt er altijd naar dit stuk verwezen. Het bevat een duidelijk klassificatie hiervan en geeft erg veel inzicht in alle vormen.

[mbravenboer]

CybErik: Mij wel, programmeertalen van MS zijn hoogstwaarschijnlijk niet portable en compatible met andere besturingssystemen.

. Bestudeer eens de feiten voordat je met zulke totaal niet onderbouwde uitspraken komt. Het geeft helaas meer kortzichtigheid aan dan wijsheid. Het is natuurlijk erg stoer om je te verzetten tegen impopulaire en grote bedrijven of organisaties, maar doe dat dan wel op basis van feiten. Niet op basis van FUD.

[mbravenboer]

Otis: Mja, maar het mooie aan interfaces is juist dat je een nieuwe kunt definieren en die door andere classes kunt laten implementeren zodat je een oudere in tact houdt. Ik zie het nut totaal niet van het herschrijven van de huidige .net api omwille van generics

Dit argument gaat alleen op als je data model hetzelfde blijft. Dit data model is echter fundamenteel krachtiger geworden met de introductie van geparameterizeerde typen.

WEL zie ik het nut van het UITBREIDEN van de api omwille vn generics. En dat is ook logisch, het interface systeem vraagt daarom

Nee helemaal niet: generics bieden geen voordeel in alternatieve implementaties, maar juist in het gebruik van implementaties. Interfaces beschrijven het gebruik van implementaties. Ik ben absoluut niet gecharmeerd van bijvoorbeeld een Collections library waarin er twee takken zijn en twee interfaces (je zal immers ook interfaces voor generics moeten hebben). Code werkt dan op een bepaalde interface, waardoor er allerlei conversies mogelijk zijn.

Liever zie ik 1 interface, eventueel aangevuld met een default parameterizatie met Object.

Welnee. Je wijzigt geen interfaces van een API. Dat staat gelijk aan het killen van een api, want ieder programma zal niet meer werken met de api

Dit is niet te vergelijken met een gewone aanpassing van een interface. Normale aanpassingen gaan over het toevoegen over verwijderen van methoden of het aanpasse van argumenten of return-typen. Het gaat hier echter om een nieuw data-model.

en het is ook ONNODIG om interfaces te wijzigen: je definieert gewoon een nieuwe. Wellicht implementeren de classes van de .NET api met generics dezelfde interfaces van de 1e release PLUS de interfaces met generics. Net als in COM.

Ja joepie, laten we COM als voorbeeld nemen . Beide interfaces implementeren is overigens niet mogelijk omdat dit juist zou aangeven dat het contract wat je aangaat bij het implementeren van een geparameterizeerde interface verbroken wordt.

Maar, waarom moet men dat omschrijven? Ik zie het meer als: het werkt nu met object, als je generics wilt gebruiken, dan gebruik je de updated classes maar.

Inderdaad, waarom herschrijven? Voer dan liever een default parameterizatie met Object in (waar overigens nog flink wat nadelen aan kleven). Waarom nu al rommel invoeren in een API als een framework nog maar ongeveer een jaar uit is? Java is een rommeltje aan het worden door de vele alternatieven, laat dat alsjeblieft niet nu ook al starten bij .NET.

Dubbele classes is inderdaad wat overbodig, omdat je interfaces hebt, dus ik denk meer aan 1 class die zich voordoet als 2 verschillende, middels de verschillende interfaces.

Helaas is dat denk ik niet fraai te realiseren omdat je dan het contract van je interface wel moet verbreken.

OF ze gaan voor onderwater compilatie van bestaande code naar <Object> parametriseerde varianten

Daar zou ik voor gaan.

Ik zou het werkelijk een schop in mn tanden vinden als ze alles parametriseert maken en maar middels 'tools' de handel moet converteren.

Bij Java lossen ze dit op door de 'raw' types: je kan een geparameterizeerde klasse gebruiken zonder parameter. De Collections zullen dus gewoon vervangen worden door de geparameterizeerde variant. Ik vind raw types niet leuk, maar vind dit nog altijd een betere oplossing dat jouw voorstel over het dupliceren van de interfaces.

Stel bijvoorbeeld dat iemand geen parameterizatie gebruikt, maar z'n List door moet geven aan iets wat wel een geparameterizeerde list wil hebben? Hier zal een conversie plaats moeten vinden, waardoor je toch 'last' hebt van de generics. Hetzelfde geldt de andere kant op.

[Anoniem: 7195]

Op woensdag 03 juli 2002 10:53 schreef mbravenboer het volgende:
[..]
Nee: een cast zet iets niet om van het ene type naar het andere. Een object is van een bepaald type en een cast veranderd daar helemaal niets aan (behandel casts van primitieven even apart want dat zijn in feite expliciete conversies).

Maar, implicit casts zijn ook casts, of mis ik iets?

Een cast is een 'hack' in je code om een instantie van een bepaalde klasse te gebruiken als een specifieker type. Deze cast is mogelijk omdat jij weet dat het object van dit specifiekere type is, maar het type-systeem dit niet zelf kan afleiden en daarom een expliciete cast wil zien.

Explicit casts vind ik idd ook ergerlijk, maar dat vind ik van alle statements waarbij je je kunt afvragen of een compiler dat niet uit kan zoeken. Ik vind ze voornl. ergerlijk omdat veelal geen implicit cast operator is gedefinieerd. Je kunt dan wel gaan discussieren over of je uberhaupt implicit casts nodig hebt. Maar frankly: het is zo non-interessant: de CLR/compiler zal uberhaupt casts moeten doen tussen een blok memory en een typed class, al merk je daar niets van als developer. Zonder casts overigens geen serialization, iets dat erg veel developers een must-have feature vinden.

Als het type-systeem zelf had kunnen afleiden dat het object van dit specifiekere type is, was de cast niet nodig geweest. Vandaar dat iets als een cast bijvoorbeeld helemaal niet bestaat in hogere orde functionele talen. Het type systeem is daar zo krachtig dat casts absoluut overbodig zijn.

Mja, maar sommige operaties waar casts nodig zijn kun je niet uitvoeren in functionele talen, plus praat je over 'casts', maar bedoel je explicit casts, die je voorkomt door implicit cast operators te definieren. Je ziet ze dan niet in de code, maar ze zijn er wel. Dat is wel degelijk een verschil, want INTERN zal er uberhaupt casting plaatsvinden, ergens. Verder voorkom je casts niet bij binary objects, serialization etc, dus waar nu marshalling plaats kan vinden.

[Otis: maar je kunt nu al middels bv interfaces code reuse bewerkstellingen binnen bv C# binnen bv datastructuren, en dat zonder type-checking compromissen.]
Sorry, maar dat is echt onzinnig. Generics zorgen er juist voor dat je code kunt parameterizeren met typen. Dit zorgt voor een generieke implementatie (universele quantificatie) van een stuk code over een verzameling typen. Generics zorgen hierdoor juist voor een betere statische type-checking dan met het werken met een unvirsele superklasse als Object.

Jaja, maar WAAR heb je generieke implementaties nodig, waar je NIET toekunt met bv een interface? Generieke implementaties van stukken code waar generieke eisen niets toevoegen aan de functionaliteit, lijkt mij overbodig. Het lijkt erop alsof alle code met generieke functies en classes er enorm op vooruit gaat maar dat is onzin. Alleen universele bouwstenen zoals collections, sorteringmethods etc etc, die zijn middels generics universeler te bouwen en zorgen voor het verdwijnen van explicit casts. Een class die een zekere businessrule uitvoert schiet daar weinig mee op hoor.

Neem bijvoorbeeld eens een sorteer algoritme:

code:

public List sort(List list)

Er is geen enkele garantie dat de typen van de items in de list hetzelfde blijft tijdens het sorteren. Dit verwacht je uiteraard wel, maar het is niet gedocumenteerd in de code zelf en de compileer kan er absoluut geen uitspraak over doen.
Als je een item uit de List wilt halen zal je een cast moet doen, wat dus een hack in het type-systeem is.
Als je echter dit bekijkt:

code:

public <T> List<T> sort(List<T> list)

Heb je at compile time een stuk meer duidelijkheid, om het nog maar geeneens te hebben over de documenterende waarde. Dit signatuur geeft aan dat deze methode voor alle typen T (universele quantificatie) een sorteer methode implementeert die als parameter een List of Ts neemt en een List of Ts oplevert. Daar kan je iets mee: een cast is niet meer nodig omdat het type systeem zelf kan garanderen dat een object van type T is als je het uit de List haalt.

Ja, maar sorteeralgoritmen zitten normaliter in een API, die implementeer je niet zelf. Dat is mn punt: ZELF generics gebruiken in je eigen code, dus je eigen code parametriseren, lijkt me niet echt voor de hand liggen zodra de api van bv .NET geparametriseerd is. Waarom zou je nog? Alle datastructuren en methods die geparametriseerd zouden kunnen worden zijn dat al en zitten in de api. Anders kun je het ook nog middels een interface doen. In de C RTE bv zit een quicksort functie, die is universeel. Zonder generics. Je levert zelf een interface implementatie aan.

Ergo: de consumer van een goedgebouwde API die generics ondersteunt heeft generics echt zelden nodig in zn eigen code.

[mbravenboer]

OMX2000: heeft iemand al ervaring met dynamic typed programmeer talen zoals Smalltalk.

Weleens mee gespeeld, maar niet intensief en zeker niet in een serieus project.

Ik vond het een beetje jammer dat MS daar niet voor gekozen heeft in .Net.

Ik denk dat een Smalltalk achtig iets als 'opvolger' van C++ en alternatief voor Java toch wel een beetje erg revolutionair is .

Op zich is er niets mis met statisch getypeerde talen, maar het grote probleem met de huidige generatie OO-talen is dat het type-systeem slap is, niet zozeer dat ze statisch getypeerd zijn. Een statisch getypeerde taal in combinatie met een zwak type-systeem is vervelend.

Er zijn bijvoorbeeld veel statische getypeerde hogere order functionele talen (Haskell bijvoorbeeld) waar over het algemeen toch geen enkel bezwaar tegen de statische typering is.

[Anoniem: 55933]

Op woensdag 03 juli 2002 10:57 schreef mbravenboer het volgende:

[..]

. Bestudeer eens de feiten voordat je met zulke totaal niet onderbouwde uitspraken komt. Het geeft helaas meer kortzichtigheid aan dan wijsheid. Het is natuurlijk erg stoer om je te verzetten tegen impopulaire en grote bedrijven of organisaties, maar doe dat dan wel op basis van feiten. Niet op basis van FUD.

Het is een feit dat programmeertalen en omgevingen tot nu toe niet portable zijn geweest naar andere OS'es (Linux en MacOS bijvoorbeeld), en dat zal waarschijnlijk niet veranderen met C#. Of heb jij dan wel Visual Basic/C++/whatever van MS op Linux zien draaien? Lijkt me sterk.

[Anoniem: 7195]

Op woensdag 03 juli 2002 11:09 schreef mbravenboer het volgende:
[..]
Dit argument gaat alleen op als je data model hetzelfde blijft. Dit data model is echter fundamenteel krachtiger geworden met de introductie van geparameterizeerde typen.

We hebben het over bestaande code. Dat verandert dus niet.

[..]
Nee helemaal niet: generics bieden geen voordeel in alternatieve implementaties, maar juist in het gebruik van implementaties. Interfaces beschrijven het gebruik van implementaties. Ik ben absoluut niet gecharmeerd van bijvoorbeeld een Collections library waarin er twee takken zijn en twee interfaces (je zal immers ook interfaces voor generics moeten hebben). Code werkt dan op een bepaalde interface, waardoor er allerlei conversies mogelijk zijn.

Waarom? HOE de collection is opgeslagen is toch niet interessant! Hoe je ermee werkt wel. Als .Add(Object) een object toevoegt volgens de oude methodiek, zul je dat moeten blijven doen. Je kunt niet EISEN van developers dat ze de huidige codebase die ze hebben geschreven 'even converteren, want we hebben iets nieuws bedacht'. Geen een API developer ter wereld doet dat bij zn api-consumers. En terecht.

[..]
Dit is niet te vergelijken met een gewone aanpassing van een interface. Normale aanpassingen gaan over het toevoegen over verwijderen van methoden of het aanpasse van argumenten of return-typen. Het gaat hier echter om een nieuw data-model.

Nee, het gaat hier niet om een nieuw datamodel, maar over universialiteit in methods. Het toevoegen van 200 .Add(type) methods zal hetzelfde bereiken. Verandert dan het datamodel? Ik denk het niet. Functioneel verandert er iets dmv generics: men kan de collection typeren en dus alleen typen toelaten van het type waarmee de collection is gecreeerd. Of de blokjes data nu 'object' zijn of 'MyClass', boeit dat mbt het datamodel? Ik zie niet in waarom. Het collectionobject heeft er zelf geen weet van namelijk.

[..]
Ja joepie, laten we COM als voorbeeld nemen . Beide interfaces implementeren is overigens niet mogelijk omdat dit juist zou aangeven dat het contract wat je aangaat bij het implementeren van een geparameterizeerde interface verbroken wordt.

Ik zie niet in waarom. De geparametriseerde interface heeft meer methods, nl. de geparametriseerde methods, constructor(s) etc. De niet-geparametriseerde niet, die heeft alleen de oude. Als je een reference legt naar een object middels de 1e interface, kun je alleen de ene set methods aanroepen, met een reference naar de 2e interface de 2e set methods (duh), waar wordt iets verbroken? Een interface is alleen een opdracht dat de in de interface gedefinieerde methods / properties ook daadwerkelijk worden geimplementeerd, dat doe je dan toch?

[..]
Inderdaad, waarom herschrijven? Voer dan liever een default parameterizatie met Object in (waar overigens nog flink wat nadelen aan kleven). Waarom nu al rommel invoeren in een API als een framework nog maar ongeveer een jaar uit is? Java is een rommeltje aan het worden door de vele alternatieven, laat dat alsjeblieft niet nu ook al starten bij .NET.

Mja, ik snap echt niet waarom je niet inziet dat het wijzigen van de huidige api en het VERPLICHTEN tot converteren van bestaande code (die er al is in grote getale!) een inmens nadeel is en ik denk de nekslag zal zijn voor de acceptatie van het framework. Immers: 'what's next?' ? Dat een complete namespace wordt vervangen door twee andere omdat dat beter is? Zo werkt het niet: interface gedefinieerd? interface is here to stay.

Stel bijvoorbeeld dat iemand geen parameterizatie gebruikt, maar z'n List door moet geven aan iets wat wel een geparameterizeerde list wil hebben? Hier zal een conversie plaats moeten vinden, waardoor je toch 'last' hebt van de generics. Hetzelfde geldt de andere kant op.

Ten eerste zal dit niet voorkomen in de huidige code, plus wanneer je de huidige interfaces handhaaft. Ten tweede kun je simpelweg de eis stellen dat non-parametriseerde classes niet kunnen worden doorgegeven aan geparametriseerde methods, tenzij de geparametriseerde method ook <Object> aankan, want de non-parametriseerde class IS een <Object> geparametriseerde variant. Er is 1 verschil echter: een geparametriseerde method verwacht per type een dictionairy. Een non-parametriseerde methodcall maakt die niet aan NU, dus in de CLR zul je die wel aan moeten maken. Wat ik ervan begreep willen ze dat gaan doen bij het opbouwen van de datastructuur, dus in het geval van de non-parametriseerde class, moet de CLR daar toch dictionairies voor aanmaken.

Wat er imho op wijst dat ze idd gaan voor onderwater compilatie naar Class<Object>, want dan vang je dat meteen op.

[Anoniem: 7195]

Op woensdag 03 juli 2002 11:21 schreef CybErik het volgende:
[..]
Het is een feit dat programmeertalen en omgevingen tot nu toe niet portable zijn geweest naar andere OS'es (Linux en MacOS bijvoorbeeld), en dat zal waarschijnlijk niet veranderen met C#. Of heb jij dan wel Visual Basic/C++/whatever van MS op Linux zien draaien? Lijkt me sterk.

C# runt op Freebsd en Linux middels Rotor, de shared source CLI, en middels Mono op linux.

C++ is nooit portable, tenzij je louter RT lib functies gebruikt.

En als jij jezelf wilt belemmeren door niet voor MS talen te kiezen, veel plezier nog in Perl op Linux.

[mbravenboer]

Otis: Maar, implicit casts zijn ook casts, of mis ik iets?

Er bestaan imho geen impliciete casts: alleen impliciete conversies. Een cast wordt over het algemeen gezien als een harde specialisering van een object naar een bepaald type. Een impliciete cast is daardoor onzinnig: als dit impliciet gedaan zou kunnen worden, zou de cast helemaal niet nodig zijn (er even vanuit gaande dat een taal alleen impliciete casts/conversies toelaat las hij zelf kan garanderen dat deze cast/conversie uitgevoerd kan worden.

Soms wordt het meegeven van een object van een specifieker type naar een methode met een generiekere parameter weleens een cast genoemd, maar eigenlijk vind ik dat geen prettige manier van denken als je een beetje abstract naar OO kijkt.

Ik ben blij dat mijn C# boek dit onderscheid duidelijk maakt:

Implicit conversions are those that will always succeed; the conversion can always be performed without data loss.

Naast impliciete conversions zijn er ook expliciete conversions. Hieronder vallen bijvoorbeeld de conversie van een uint naar een byte (die je wel checked kan maken).

Explicit casts vind ik idd ook ergerlijk, maar dat vind ik van alle statements waarbij je je kunt afvragen of een compiler dat niet uit kan zoeken.

Maar alle casts die je zelf tikt zijn expliciet

Maar goed, daar zijn we het nu wel goed eens (alhoewel je denk ik iets anders bedoelt ). Mijn hele verhaal gaat er juist over dat generics er voor zorgen dat de compiler op basis van het type systeem meer kan uitzoeken: de expliciete casts zijn daardoor niet nodig.

Mja, maar sommige operaties waar casts nodig zijn kun je niet uitvoeren in functionele talen, plus praat je over 'casts', maar bedoel je explicit casts, die je voorkomt door implicit cast operators te definieren.

Ik vindt een impliciete (user-defined of niet) conversie geen cast, maar je zou dus kunnen zeggen dat ik in feite alleen expliciete casts bedoel. Ik vind dit onderscheid echter niet prettig omdat expliciet <-> impliciet meer een kestie van syntaxtische suiker is. Ik zie een cast als een specialisatie van een object zonder het object zelf aan te passen. Impliciete conversies, maken echter vaak een nieuw object en als een implicite conversie in feite een expliciete cast uitvoert is dit erg verkeerd: een expliciete cast is niet veilig, omdat de cast anders helemaal niet nodig zou zijn. Volgens de guidelines moeten impliciete conversies echter wel safe zijn.

Het lijkt erop alsof alle code met generieke functies en classes er enorm op vooruit gaat maar dat is onzin.

Alle code die over meerdere typen kan werken gaat erop vooruit. Met name ook in het gebruik van deze code. Collections zijn hiervan een heel typisch voorbeeld, maar je kan nog wel wat meer verzinnen.

Een class die een zekere businessrule uitvoert schiet daar weinig mee op hoor.

Gelukkig is ook niet heel de wereld bezig met business-rules .

ZELF generics gebruiken in je eigen code, dus je eigen code parametriseren, lijkt me niet echt voor de hand liggen zodra de api van bv .NET geparametriseerd is.

Juist ook in het gebruik van code die geparameterizeerd is heb je veel voordeel. Generics hebben juist doordat ze een aanpassing van het data-model zijn een grote invloed op het gebruik van een API.

Ergo: de consumer van een goedgebouwde API die generics ondersteunt heeft generics echt zelden nodig in zn eigen code.

Generics ondersteun je juist om een goede interface te bieden. Een typisch voorbeeld is de sort methode: de interface naar dit algoritme garandeerd dat er een List<T> terugkomt. De gebruiker van dit sorterings-algoritme kan dit benutten.

[mbravenboer]

Otis zei het al, maar ik doe er nog even een schepje bovenop .

CybErik: Het is een feit dat programmeertalen en omgevingen tot nu toe niet portable zijn geweest naar andere OS'es (Linux en MacOS bijvoorbeeld), en dat zal waarschijnlijk niet veranderen met C#.

Dat is dus een onjuiste aanname die duidelijk aangeeft dat je absoluut niet geinformeerd bent. Weleens van Mono gehoord? Ik kan hier C# compileren en draaien onder Mono. Mono heeft geen VB .NET compiler, maar dat kan ik even compileren onder de gratis .NET Framework SDK en daarna draaien op Mono. Mooi he? .

[tazzman]

En dan ligt het er nog aan wat je EXACT wilt gaan ontwikkelen en in wat voor bedrijfsomgeving. Dat het niet portable is - tjah, ik draai toch al enige jaren mee in de IT/Dev en ik heb nog nooit meegemaakt dat men besloot 'oh we gaan onze desktop OS maar vervangen van NT4 naar een Linux variant' Wat betreft server OS/type - dat zijn doorgaans doordachte strategische beslissingen (lange termijn dus ipv tactisch) waar voor een bepaald concept gekozen wordt. En of dat Unix of WinNT/2K of later .NET wordt .. dat is niet zo'n ramp.

We hebben hier op mijn werk ook gewoon NT4/2K servers, AS400's en andere Unix mainframes - dat is niet te vermijden bij grote internationale bedrijven. Maar dat maakt voor de keuze van Dev taal niet echt veel uit omdat ik nog nooit meegemaakt heb dat een ontwikkelde c/s-app of web solution ineens toch maar van die NT4 doos naar de UNIX mainframe server moet. Sterker nog, zoals het er nu uitziet zullen de Unix dozen aanblijven als Oracle servers maar de c/s-app servers en webservers zullen toch Win2K servers worden en deze trent zal alleen maar groeien.

Dat het portable is of niet .. is in mijn werkomgeving niet zo enorm van belang. Maar dat kan overal en voor iedereen anders zijn natuurlijk.

[mbravenboer]

Otis: Waarom? HOE de collection is opgeslagen is toch niet interessant! Hoe je ermee werkt wel. Als .Add(Object) een object toevoegt volgens de oude methodiek, zul je dat moeten blijven doen.

Het gaat helemaal niet om de opslag. Generics hebben alles te maken met de interface naar een API. Generics voorkomen namelijk casts en casts hebben te maken met de interface naar een API.

Waarom zou je developers wel vermoeien met twee verschillende APIs voor hetzelfde werk?

Deze problemen geven ook precies aan waarom ik zoveel kritiek had op de late invoering van generics. Zelfs nu .NET zo jong is, signaleer je al ontzettend veel problemen die voorkomen waren als geparameterizeerde typen gelijk waren opgenomen in het framework en er bij het ontwerp eventueel keuzen konden worden gemaakt of je verplicht bent om die parameterizatie te gebruiken of niet.

Nu zijn ze verplicht om een keuze te maken: of mij blij maken, of jou erg boos maken. Puristen versus mensen met legacy code.[quote]
Geen een API developer ter wereld doet dat bij zn api-consumers. En terecht.[/qupte]
Java dus wel . Het staat echter raw-types toe en dat vind ik een prettigere oplossing dan het aanbieden van twee interfaces.

Nee, het gaat hier niet om een nieuw datamodel, maar over universialiteit in methods. Het toevoegen van 200 Add(type) methods zal hetzelfde bereiken.

Nee: het toevoegen van 200 Add methoden is geen universele quantificatie. Generics wel.

Of de blokjes data nu 'object' zijn of 'MyClass', boeit dat mbt het datamodel? Ik zie niet in waarom. Het collectionobject heeft er zelf geen weet van namelijk.

Yepz, dat boeit wel degelijk. Bij een geparameterizeerde collection kan de compiler namelijkl garanderen dat een Get ook daadwerkelijk een bepaald type oplevert. Met 200 Add methoden en 200 Get methoden los je dat niet op. Het boeit daarom wel degelijk of de blokjes data Object of MyClass zijn: alleen omdat ze van MyClass zijn kan de compiler via het type-systeem garanderen dat een Get methode ook daadwerkelijk een MyClass instantie oplevert.

Ik zie niet in waarom. De geparametriseerde interface heeft meer methods, nl. de geparametriseerde methods, constructor(s) etc.

Zowel de oude als de nieuwe interface hebben een Get methode bij bijvoorbeeld een List. Beide hebben echter een verschillend return type. Wil je de naam van de geparameterizeerde methode dan maar gaan aanpassen? Dat lijkt me pas echt ranzig .

Mja, ik snap echt niet waarom je niet inziet dat het wijzigen van de huidige api en het VERPLICHTEN tot converteren van bestaande code (die er al is in grote getale!) een inmens nadeel is en ik denk de nekslag zal zijn voor de acceptatie van het framework. Immers: 'what's next?' ?

Ik zie ook wel degelijk in dat het wijzigen van de API een ontzettend nadeel is en daarom vind ik het ook onzettend stom dat ze zo'n belangrijke uitbreiding al plannen vlak na het uitkomen van het framework. Had dan liever een half jaar gewacht en er harder aan gewerkt.

Ik zie echter ook grote nadelen in duplicatie van interfaces en alternatieven. Deze nadelen ervaar ik zelf dagelijks als in Java programmeer.

Nu .NET nog weinig legacy code kent, zie ik liever dat ze niet nu al een grote tweedeling gaan aanleggen die voor altijd problemen zal blijven veroorzaken.

"What's next" vind ik niet helemaal terecht omdat geparameterizeerde typen een fundamentele uitbreiding zijn en niet zomaar een leuke feature die Microsoft heeft bedacht.

Wat er imho op wijst dat ze idd gaan voor onderwater compilatie naar Class<Object>, want dan vang je dat meteen op.

Dat hoop ik en ik hoop dat ze ook zo met legacy code omgaan....

[curry684]

Op woensdag 03 juli 2002 10:53 schreef mbravenboer het volgende:
Een cast is een 'hack' in je code om een instantie van een bepaalde klasse te gebruiken als een specifieker type. Deze cast is mogelijk omdat jij weet dat het object van dit specifiekere type is, maar het type-systeem dit niet zelf kan afleiden en daarom een expliciete cast wil zien.

Urm ooit gehoord van dynamic_cast? Die gebruik je juist omdat je niet weet of iets op runtime van een bepaald type is (even een VCL-style voorbeeld):

code:

String LeesInvoer(TControl* p_Control)
{
TEdit*     l_Edit = dynamic_cast<TEdit*>(p_Control);

if(l_Edit)
  return l_Edit->Text;
else
  return p_Control->Caption;
}

De dynamic_cast is dus echt een runtime helper en geen 'hack' zoals je beweert.

En zelfs in C++ is de C-style cast erg nuttig in bepaalde constructies waarbij je dus inderdaad weet wat voor class je aan de haak hebt en je niet de overhead wil hebben van dynamic casts (voor de duidelijkheid: we hebben hier ooit een benchmarkje op gedaan en het verschil was een factor 186!!! )

[Soultaker]

Op woensdag 03 juli 2002 14:43 schreef curry684 het volgende:
Urm ooit gehoord van dynamic_cast? Die gebruik je juist omdat je niet weet of iets op runtime van een bepaald type is (even een VCL-style voorbeeld):

Hmm, misschien moet je even mijn discussie met Otis in ditzelfde topic doornemen. Mijn standpunt is dat casts in een goed ontwerp niet nodig zijn en ik ben wel benieuwd naar een casus die het tegendeel bewijst.

Naar mijn mening worden (zelfs dynamic) casts vaak gebruikt om snel praktische zaken te implementeren, die anders (netter) hadden gekund.

code:

String LeesInvoer(TControl* p_Control)
{
TEdit*     l_Edit = dynamic_cast<TEdit*>(p_Control);

if(l_Edit)
  return l_Edit->Text;
else
  return p_Control->Caption;
}

Ook dit is duidelijk een hack. Uit de code maak ik op dat elke TControl een bepaalde invoer-string (whatever that is) kan geven, maar Edit controls een ander soort dan andere Controls.

Het geven van de geschikt invoer-string is een typische taak van control. Wat daar precies in staat, is ook een eigenschap van die control. Het zou dus ideaal zijn, om LeesInvoer als methode van Control in te voeren (die Caption returned) en die bij een Edit te overriden (door 'm daar Text te laten returnen).

Nu neem ik aan dat TEdit en TControl klassen zijn die door je framework worden aangeboden en dus niet zomaar uit te breiden zijn. Dat is natuurlijk jammer en rechtvaardigt het gebruik van een cast misschien als je het type maar één keer nodig hebt.

Als je echter vaker onderscheid wilt maken, is het handig om een bridge/wrapper klasse te maken, die ook als TControl/TEdit/TWhatever te gebruiken is (dit kan eenvoudig in C++; minder eenvoudig in bijvoorbeeld Java) en die de extra methode te laten definiëren.

Het probleem blijft natuurlijk, dat wanneer je framework je gegeneraliseerde objecten aanbiedt en ervan uitgaat dat je met dynamic casts wel achter het juiste type kunt komen, je er niet aan ontkomt om die dynamic casts ook echt te gebruiken. In dat geval heb je geen andere keuze.

[Anoniem: 7195]

Mind you: 'netter', 'beter' etc zijn subjectieve begrippen. Ik vind een dynamic_cast helemaal niet 'minder netjes'. Wat ik bv lelijk zou vinden is een complete wrapper class om 1 dynamic_cast te omzeilen. De cast zit in de taal, is speciaal toegevoegd in C++, dus is bedoeld voor C++ constructies. Nu kan men zeuren totdat men een ons weegt, Straustrupp zal die casts er niet voor jan doedel ingestopt hebben, achter de schermen heb je nl. nogal wat compiler logica nodig.