[c++] Heeft een nieuwe versie nog zin?

[flowerp]

Ik vraag me af hoe mensen hier denken over de eventuele nieuwe versie van C++ die ooit schijnt te gaan komen.

Zoals bekend is de huidige C++ standaard C++98 nog steeds niet algemeen geimplementeerd. Sommige compilers implementeren dichtbij de 100%, anderen niet. Als je de lijntjes een beetje door trekt dan zal waarschijnlijk pas zo rond 2008 de meerderheid van de C++ compilers C++98 compliant zijn. De gehele implementatie heeft dan een goede 10 jaar geduurt.

Stel dat de nieuwe specificatie voor C++ ook in 2008 uitkomt. Het zal dan nog tot 2018 kunnen duren voor de compilers weer compliant zijn. Nu wordt C++ momenteel veel minder gebruikt dan in 1998. Nieuwe Windows applicaties gebruiken vaak C#, server side zie je voornamelijk PHP, C# en Java, embedded zie je C, mobile zie je weer Java, Linux doet bijna alleen C vanwege de "objects are evil philosophy" (die ik zelf niet snap, maar goed), en Mac OS X doet weer voornamelijk objective C voor nieuwe Apps. Alleen in games wordt, als ik het goed heb, nog veel C++ gebruikt.

De vraag is echter, zal een nieuwe revisie van C++ nog zin hebben? 2018 is nog ver weg, en het is maar de vraag of dat gehaald gaat worden. Gezien de uber-traagheid van het standaard comittee zou ik niet verbaast zijn als de publicatie pas na 2010 zal plaatsvinden, zodat we tot ver na 2020 moeten wachten voor een algemene implementatie.

Probleem is dat C++ dan mischien een beetje aan het C fenomeen gaat leiden: een klein groepje verstokte programmeurs die hun C als een afgeronde standaard ziet en niet openstaan voor nieuwe dingen. C99 werd bijvoorbeeld ook gewoon niet opgepikt.

Wat denken de mensen hier? Moet de nieuwe spec maar gewoon gedropped worden omdat het toch hopenloos is of zou het beter voor C++ zijn als er gewoon regelmatig updates kwamen en de compiler bouwers deze updates gewoon binnen het jaar verwerkt zouden hebben in hun produkten?

[Yoshi|IA2]

Als je eens kijkt naar de SQL standaard: ik geloof dat nu ongeveer SQL92 geimplementeerd is bij alle dbms'en. Het is niet zo dat een taal pas goed is als hij elke 2 jaar vernieuwd wordt... Als een taal compleet is, kun je er alles mee uitdrukken...

[frickY]

Ik wist niet dat C++ nog door ontwikkeld wordt, of zou worden?
Ik dacht dat dat bij wijze van spreken 'klaar' was, en C# de opvolger is waar alle tijd in wordt gestoken?

[flowerp]

Yoshi schreef op zondag 12 februari 2006 @ 14:28:
Als je eens kijkt naar de SQL standaard: ik geloof dat nu ongeveer SQL92 geimplementeerd is bij alle dbms'en. Het is niet zo dat een taal pas goed is als hij elke 2 jaar vernieuwd wordt... Als een taal compleet is, kun je er alles mee uitdrukken...

Inderdaad ja. Met alle 2 de dingen die je zegt eens. Heel erg lang geleden leerde ik nog op school dat er ooit een SQL3 zou komen in het toen nog verre en futoristische jaar 2000

Ook als een taal compleet is, dan kun je er idd alles mee uitdrukken. LaTeX is zo'n taal die compleet is en nooit meer uitgebreid kan (mag!) worden.

Maar hoe zit dit met C++? Is de taal werkelijk compleet? Is het nou bijvoorbeeld echt handig om een type-unsafe enum te hebben ipv een type-safe enum (om maar eens wat te noemen).

Ik wist niet dat C++ nog door ontwikkeld wordt, of zou worden?
Ik dacht dat dat bij wijze van spreken 'klaar' was, en C# de opvolger is waar alle tijd in wordt gestoken?

Jouw quote geeft inderdaad wel aan hoe er bij het 'gewone' publiek over gedacht wordt. Dit hoor ik inderdaad veel vaker. Men is al jaren bezig om tot de 2de versie van C++ te komen, die werd altijd C++0x genoemt. Vroeger dachten we altijd dat x een 5 zou worden, maar ja... we zitten nu al in 2006 dus die 5 gaat het zeker niet meer worden.

Lange tijd schreef Herb Sutter in C++ Users Journal hier regelmatig over, maar dat is de laatste tijd een beetje stil geworden. Heel recent hebben we wel weer iets van Bjarne hierover gehoord: http://www.artima.com/cppsource/cpp0x.html

Die x schijnt nu een 9 te worden, maar eigenlijk geloof ik er zelf niet meer zo in. Dat jij C# als opvolger ziet is ook wel grappig. Je zou het niet zeggen, maar verschillende mensen uit de C++ community hebben ook kenbaar gemaakt dat zei inderdaad goed naar C# moeten kijken voor de evolutie van hun taal.

[ Voor 39% gewijzigd door flowerp op 12-02-2006 14:41 ]

[Zoijar]

flowerp schreef op zondag 12 februari 2006 @ 14:17:
Ik vraag me af hoe mensen hier denken over de eventuele nieuwe versie van C++ die ooit schijnt te gaan komen.

The holy grail

Zoals bekend is de huidige C++ standaard C++98 nog steeds niet algemeen geimplementeerd. Sommige compilers implementeren dichtbij de 100%, anderen niet. Als je de lijntjes een beetje door trekt dan zal waarschijnlijk pas zo rond 2008 de meerderheid van de C++ compilers C++98 compliant zijn. De gehele implementatie heeft dan een goede 10 jaar geduurt.

C++98 wordt momenteel goed ondersteund hoor, zat grote compilers die compliant zijn (althans, voor 99.5% oid)

Stel dat de nieuwe specificatie voor C++ ook in 2008 uitkomt. Het zal dan nog tot 2018 kunnen duren voor de compilers weer compliant zijn. Nu wordt C++ momenteel veel minder gebruikt dan in 1998. Nieuwe Windows applicaties gebruiken vaak C#, server side zie je voornamelijk PHP, C# en Java, embedded zie je C, mobile zie je weer Java, Linux doet bijna alleen C vanwege de "objects are evil philosophy" (die ik zelf niet snap, maar goed), en Mac OS X doet weer voornamelijk objective C voor nieuwe Apps. Alleen in games wordt, als ik het goed heb, nog veel C++ gebruikt.

Volgens deze cijfers:

http://www.cs.berkeley.edu/~flab/languages.html

is C++ nog steeds de koploper. Granted, dat is data van 2004, maar als je nu het aantal projects op sourceforge kijkt, staat C++ gedeeld eerste met Java.

De vraag is echter, zal een nieuwe revisie van C++ nog zin hebben? 2018 is nog ver weg, en het is maar de vraag of dat gehaald gaat worden. Gezien de uber-traagheid van het standaard comittee zou ik niet verbaast zijn als de publicatie pas na 2010 zal plaatsvinden, zodat we tot ver na 2020 moeten wachten voor een algemene implementatie.

Probleem is dat C++ dan mischien een beetje aan het C fenomeen gaat leiden: een klein groepje verstokte programmeurs die hun C als een afgeronde standaard ziet en niet openstaan voor nieuwe dingen. C99 werd bijvoorbeeld ook gewoon niet opgepikt.

Wat denken de mensen hier? Moet de nieuwe spec maar gewoon gedropped worden omdat het toch hopenloos is of zou het beter voor C++ zijn als er gewoon regelmatig updates kwamen en de compiler bouwers deze updates gewoon binnen het jaar verwerkt zouden hebben in hun produkten?

Nee, de nieuwe spec gaat het een nog betere taal maken. C++ is op dit moment de meest generieke taal, en ondersteunt als enige productie taal een generiek programmeer model. Dat is de toekomst voor het programmeren, OOP is uit, GP is in. Zeker wetenschappelijke applicaties zullen steeds meer in GP gedaan worden. C++ ondersteunt dat model nu al redelijk, en met de nieuwe versie waarschijnlijk volledig en gebruikersvriendelijk.

(overigens zou ik graag rechtstreekse ondersteuning voor meta programming hebben, zoals C#...dat is wel iets goeds)

(nog iets, een groot deel van C++0x is al geimplementeerd in Boost. Als je C++ gebruikt zonder Boost loop je hopeloos achter)

[ Voor 6% gewijzigd door Zoijar op 12-02-2006 15:05 ]

[NMe]

flowerp schreef op zondag 12 februari 2006 @ 14:17:
Nieuwe Windows applicaties gebruiken vaak C#,

Dat gaat maar deels op natuurlijk. C# is vooral handig wanneer je iets met een database wil doen, of iets anders dat op het bedrijfskundige informatica-vlak speelt. C++ wordt nog redelijk veel gebruikt voor standaardapplicaties die niets met databases doen.

embedded zie je C,

Voornamelijk, ja. C++ komt ook nog wel eens voor heb ik gemerkt, tot mijn verrassing.

mobile zie je weer Java,

Dat hangt af van het platform waar je mee werkt. Software voor Symbian bijvoorbeeld wordt voornamelijk geschreven in C++; sterker nog, Java-programma's werken absoluut niet fijn in Symbian door de vrij brakke Java-support.

Linux doet bijna alleen C vanwege de "objects are evil philosophy" (die ik zelf niet snap, maar goed),

AFAIK had dat meer te maken met het feit dat veel Linuxgebruikers hun apps zelf willen compileren, en de compileertijd van C-programma's ligt iets lager dan die van C++-programma's. In hoeverre dat waar is weet ik niet, het is maar wat een klasgenoot annex Linux-goeroe me eens vertelde.

De vraag is echter, zal een nieuwe revisie van C++ nog zin hebben? 2018 is nog ver weg, en het is maar de vraag of dat gehaald gaat worden.

Het is natuurlijk niet zo dat de huidige standaard nu pas goed geïmplementeerd wordt ofzo. De huidige standaard wordt al jaren voor 99,x% ondersteund door alle bekende compilers, dus zo traag gaat het allemaal niet. Ik verwacht dat, als er een nieuwe standaard komt, deze wel binnen een paar jaar verwerkt zal zitten in de bekendere compilers. Dat dat wellicht niet voor de volledige 100% zal zijn, tsja, het zij zo. 100% standard-compliant zijn lijkt me sowieso lastig.

Probleem is dat C++ dan mischien een beetje aan het C fenomeen gaat leiden: een klein groepje verstokte programmeurs die hun C als een afgeronde standaard ziet en niet openstaan voor nieuwe dingen.

Wat zie jij dan als goed alternatief voor C++? C# is voornamelijk (alleen?) voor .NET bedoeld, Java is afhankelijk van een VM en gewoon sowieso niet geschikt voor low-level dingen zoals het maken van drivers, Delphi/Object Pascal wordt op eenzelfde niveau onderhouden als C++ en verder zijn er volgens mij niet echt duidelijke gegadigden.

[Boudewijn]

frickY schreef op zondag 12 februari 2006 @ 14:31:
Ik wist niet dat C++ nog door ontwikkeld wordt, of zou worden?
Ik dacht dat dat bij wijze van spreken 'klaar' was, en C# de opvolger is waar alle tijd in wordt gestoken?

er is meer dan alleen microsoft en hun propagandistische praat

[flowerp]

Zoijar schreef op zondag 12 februari 2006 @ 15:01:
[...]
The holy grail

Tenminste 1 iemand die er positief over is!

C++98 wordt momenteel goed ondersteund hoor, zat grote compilers die compliant zijn (althans, voor 99.5% oid)

Wetenschappelijk en technisch gezien is dat natuurlijk raar. Een standaard is een standaard als gewoon elk produkt het 100% implementeerd. Nu wil ik Java als taal niet al te veel gaan ophemelen, maar daar werd de nieuwe spec wel degelijk binnen het jaar geimplementeerd door 3rd parties. Natuurlijk telt de implementatie van Sun niet echt mee, want die maken een compiler en zeggen dit is de standaard. Maar een externe partij als Eclipse kwam gewoon na 1 jaar met een implementatie en die was dan ook gewoon 100%.

Ook voor andere dingen geldt dit. Java EE word ook gepubliceert als een spec, en vendors doen er dan zeker geen 10 jaar over om die te implementeren. Zeker de STL was voor C++ in het begin een ramp. Nergens een implementatie te krijgen, alleen SGI had toen iets maar dat had ook weer beperkingen.

Let op, ik zeg niet dat Java zelf beter is. Verre van dat. C++ heeft enorm veel voordelen en is in het algemeen een sterkere taal. Wat ik bedoel is dat het me een beetje verbaast waarom het allemaal zo onmogelijk lang moet duren.

(overigens zou ik graag rechtstreekse ondersteuning voor meta programming hebben, zoals C#...dat is wel iets goeds)

Dat is inderdaad wel erg mooi. Het is zoals Bjarne dat uitdrukt iets wat je anders doet denken, een declaratieve style van programmeren wat dicht tegen AOP aanzit. Toch zie je al (maar dat gebeurd vrijwel overal mee), dat het in de praktijk ook misbruikt wordt. Het is namelijk zo heel makkelijk om allemaal configuraties en resources in je code te gaan opnemen (bv, DB URL voor Connections, of zelfs complete SQL text voor queries in meta data stoppen). Beide zijn niet echt de bedoeling van het concept.

[flowerp]

-NMe- schreef op zondag 12 februari 2006 @ 15:15:
[...]

Dat gaat maar deels op natuurlijk. C# is vooral handig wanneer je iets met een database wil doen, of iets anders dat op het bedrijfskundige informatica-vlak speelt. C++ wordt nog redelijk veel gebruikt voor standaardapplicaties die niets met databases doen.

Is dat zo? Ik bevind me nu enigzins op glad terrein omdat ik al een tijdje geen Windows applicaties meer schrijf, maar ik had juist begrepen dat C# voor ELK Windows programma wat een GUI laat zien (de meerderheid dus) de aangewezen keuze is. Veel mensen willen namelijk niet rechtstreeks tegen de win32 API aan programmeren. Dat is een enorm vervelend karwei gebasseerd op een vrij oud paradigma. -DE- C++ Windows 'API'/wrapper MFC wordt al jaren lang totaal niet meer ontwikkeld. Wil je dus een Windows programma schrijven met gebruik making van de moderne widgets, dan kom je al meteen op .NET uit, en die drukt je toch zeer snel richting C#.

Een klein lichtpuntje is wel dat je tegenwoordig met VS 2005 ook uitstekend C++ kan gebruiken op .NET. Het is dan wel weer geen 100% pure C++, maar toch. Ik heb eigenlijk vrij weinig inzicht in hoeveel programmeurs of bedrijven nu C++ kiezen voor nieuwe .NET projecten. Ik zou zeggen kwa gevoel dat de eerste keuze toch C# is en blijft.

AFAIK had dat meer te maken met het feit dat veel Linuxgebruikers hun apps zelf willen compileren, en de compileertijd van C-programma's ligt iets lager dan die van C++-programma's. In hoeverre dat waar is weet ik niet, het is maar wat een klasgenoot annex Linux-goeroe me eens vertelde.

Ik vraag het mezelf ook al tijden af. Er zit geen specificieke license aan C++ die het gebruik zou tegenhouden. Ik ben er zelf wel eens naar op zoek geweest, maar dan kom je vaak op usenet discussies uit die moeilijk te volgen zijn. Veel meer dan het "objects are evil" begrijp ik er dan ook niet uit. Overigens gebruikt Qt (gtk) natuurlijk wel weer C++, alhoewel ook dat een beetje 'mangled' is...

Het is natuurlijk niet zo dat de huidige standaard nu pas goed geïmplementeerd wordt ofzo. De huidige standaard wordt al jaren voor 99,x% ondersteund door alle bekende compilers

Dat valt toch wel mee? Iniedergeval in 2002 zaten de meeste toch nog een stuk lager. VC 2002 zat zeker nog niet op de 99% en dat was toen 1 van de koplopers. GCC lag helemaal een stuk lager.

Wat zie jij dan als goed alternatief voor C++?

Persoonlijk had ik willen zien dat wat nu (waarschijnlijk) C++09 gaat worden inderdaad in 2005 op de markt was gekomen.

[H!GHGuY]

-NMe- schreef op zondag 12 februari 2006 @ 15:15:
Dat gaat maar deels op natuurlijk. C# is vooral handig wanneer je iets met een database wil doen, of iets anders dat op het bedrijfskundige informatica-vlak speelt. C++ wordt nog redelijk veel gebruikt voor standaardapplicaties die niets met databases doen.

je kan met C# heus VEEL meer doen. Persoonlijk vind ik GUI's maken in C++ maar risky en tijdrovende business. Als je even niet wakker bent maak je er een monster van of ben je urenlang bezig om iets futiel te implementeren.

Wat zie jij dan als goed alternatief voor C++? C# is voornamelijk (alleen?) voor .NET bedoeld, Java is afhankelijk van een VM en gewoon sowieso niet geschikt voor low-level dingen zoals het maken van drivers, Delphi/Object Pascal wordt op eenzelfde niveau onderhouden als C++ en verder zijn er volgens mij niet echt duidelijke gegadigden.

C# kan volgens mij nog altijd niet zonder .NET (of m0n0). Ik vind het persoonlijk een geslaagde combinatie van een managed taal als Java en de performantie en mogelijkheden van C++.

[NMe]

Zou je een driver maken in C#?

Jullie (flowerp, HIGHGuY) vergeten trouwens sowieso allebei een grote speler: Borland C++ Builder. GUI's maken is daarin niet veel meer dan click 'n play, en ik heb begrepen dat er een nieuwe versie uit is of gaat komen van C++ Builder, dus die IDE is dan zelfs nog up to date ook. De snelheid van het maken van GUI's vind ik dan ook geen reden om C++ maar af te schrijven.

[kenneth]

flowerp schreef op zondag 12 februari 2006 @ 15:44:
Overigens gebruikt Qt (gtk) natuurlijk wel weer C++, alhoewel ook dat een beetje 'mangled' is...

Qt is helemaal C++, KDE is grotendeels C++
GTK is C.

[H!GHGuY]

-NMe- schreef op zondag 12 februari 2006 @ 15:56:
Zou je een driver maken in C#?

daar is het in de eerste plaats ook niet voor gemaakt.
het is wel voor veel meer gemaakt dan enkel wat DB-apps

Jullie (flowerp, HIGHGuY) vergeten trouwens sowieso allebei een grote speler: Borland C++ Builder. GUI's maken is daarin niet veel meer dan click 'n play, en ik heb begrepen dat er een nieuwe versie uit is of gaat komen van C++ Builder, dus die IDE is dan zelfs nog up to date ook. De snelheid van het maken van GUI's vind ik dan ook geen reden om C++ maar af te schrijven.

Het maken (tekenen) van een GUI in VS6 is ook click'n'play maar het achterliggend coderen is een hel imo. Ik heb geen ervaring met Borland C++ Builder (behalve dat hun oude (DOS) compiler brak is)
dus misschien valt het allemaal nog wel mee.

[NMe]

HIGHGuY schreef op zondag 12 februari 2006 @ 16:43:
daar is het in de eerste plaats ook niet voor gemaakt.
het is wel voor veel meer gemaakt dan enkel wat DB-apps

Dat heb ik ook niet gezegd. Al snap ik, als ik mijn post zo teruglees, wel waarom je denkt dat ik dat bedoelde.

Het maken (tekenen) van een GUI in VS6 is ook click'n'play maar het achterliggend coderen is een hel imo. Ik heb geen ervaring met Borland C++ Builder (behalve dat hun oude (DOS) compiler brak is)
dus misschien valt het allemaal nog wel mee.

De oude Borland compiler voor DOS was inderdaad zwaar klote. C++ Builder is verder wel ok, afgezien dan van het feit dat Builder 6 alweer een tijdje meedraait en de opvolger redelijk lang op zich laat wachten. Het is in mijn ervaring niet zo'n hel om in te coden als VS6 af en toe kan zijn op GUI-gebied, maar dat hangt er ook een beetje vanaf hoe goed je zelf bent als programmeur. Teveel klikken en te weinig programmeren resulteert eigenlijk altijd in slecht onderhoudbare code.

Hmm, eigenlijk wel een beetje offtopic dit. Excuus.

[flowerp]

kenneth schreef op zondag 12 februari 2006 @ 15:57:
[...]
Qt is helemaal C++, KDE is grotendeels C++
GTK is C.

Ik wilde het net verbeteren maar jij was me al voor Qt is waar KDE op bouwt en is helemaal C++ met nog eigen extensions erbij. Er gaat een soort pre-compiler over de code heen om hun concept van signals en slots te ondersteunen. Aan de ene kant is het wel cool, maar ook een beetje maf eigenlijk dat een widget set zijn eigen taal elementen gaat toevoegen.

Ging Borland trouwens niet stoppen met de IDE business en zich voornamelijk richten op development life-cycle tools?

Meer on-topic, wat me nog opviel in het stukje tekst ove C++09 waar ik de link naar plaatste: C++ wordt voornamelijk onderhouden door een heel klein groepje vrijwilligers wat in hun vrije tijd (naast een full-time baan dus) wat aan C++ 'rommelt'. Eigenlijk is het vreemd dat een taal die zo'n groot economisch belang heeft wordt onderhouden door zo weinig FTE's. Dit is waarschijnlijk mede de reden dat vooruitgang in de C++ wereld zo lang duurt waar het de core language en libs betreft.

[Verwijderd]

Naar mijn idee is C++ een verouderd paradigma, wat meer en meer hoofdzakelijk voor performance-critical en low-level toepassingen zal worden gebruikt. De performance penalty die C# en Java met zich mee brengen (agv. hogere abstractie, managed code etc.) weegt in veruit de meeste gevallen nauwelijks op tegen de de productiviteitsverhoging die ontwikkeling in laatstgenoemde talen/frameworks met zich meebrengt.

[ Voor 5% gewijzigd door Verwijderd op 12-02-2006 18:00 ]

[flowerp]

Verwijderd schreef op zondag 12 februari 2006 @ 17:59:
Naar mijn idee is C++ een verouderd paradigma

No way! C++ zit mischien politiek gezien momenteel in een wat vervelend hoekje, gezien het gebruik van met name C# en Java op bepaalde gebieden. Echter het paradigma zelf is *absoluut* niet verouderd. Sterker nog, 1 van de paradigma's van C++ (generic programming) ligt ongelooflijk ver voor op de andere talen. Geen enkele mainstream taalt heeft echt generic programming.

C# en Java hebben wel iets wat ze generics noemen en wat kwa naam een beetje doet denken een generic programming. Het is echter iets compleet anders. Feitelijk komt het neer op dat de compiler types kan deduceren en daardoor automatisch casts kan invoegen in code. Kwa gebruik lijkt het wel op een bepaald aspect van generic programming, maar het is echt wat anders.

Kwa generic programming gaat C++09 nog meer mooie dingen brengen zoals de aspects (soort meta types, niet te verwarren met meta data).

Voorts mist Java nog steeds zo iets basics als operator overloading. Ga jij maar eens dingen onderhouden als a.add ( b.mul ( c.div ( d ) ) ).min( e); etc. Daar wordt je gewoon niet vrolijk van.

De performance penalty die C# en Java met zich mee brengen (agv. hogere abstractie, managed code etc.)

C# en Java hoeven niet perse sneller of langzamer te zijn. In sommige dingen is C#/Java sneller omdat een bepaald algortime moeilijk statisch te optimizen is terwijl dat runtime juist uitstekend gaat en soms is het andersom.

Managed code is in sommige gevallen wel handiger en veiliger, maar vergeet niet dat Java nog steeds resource leaks kent. Sluit bv een JDBC connection niet af (bijvoorbeeld omdat er een exception komt en je de close niet in een finally block hebt staan) en je hebt een leak. De GC lost ook alleen dangling pointer leaks op. Alloceer een groot block geheugen en stop deze in de session, en voilla, weer een potentieel leak. Draai een lange loop waarbij je vergeet een pointer op null te zetten. Tsjaka... weer een leuk.

Java heeft dan wel weer andere mooie dingen: echte type safe enums en annotations. Als platform heb je dan voornamelijk het voordeel van de immens grote standaard library. Het is gewoon bizar dat zoiets basics als reguliere expressies in C++ tot >2010 moet duren om in de standaard library te komen.

[LordLarry]

-NMe- schreef op zondag 12 februari 2006 @ 15:56:
ik heb begrepen dat er een nieuwe versie uit is of gaat komen van C++ Builder, dus die IDE is dan zelfs nog up to date ook.

[url=]Borland Developer Studio[/url] bevat de nieuwe versie van C++ Builder.

[kenneth]

flowerp schreef op zondag 12 februari 2006 @ 19:07:
C# en Java hebben wel iets wat ze generics noemen en wat kwa naam een beetje doet denken een generic programming. Het is echter iets compleet anders. Feitelijk komt het neer op dat de compiler types kan deduceren en daardoor automatisch casts kan invoegen in code. Kwa gebruik lijkt het wel op een bepaald aspect van generic programming, maar het is echt wat anders.

Die volg ik niet
Wat is het verschil tussen C# en C++ hierin?

C#:

List<Customer> foo = new List<Customer>();

[Zoijar]

Verwijderd schreef op zondag 12 februari 2006 @ 17:59:
Naar mijn idee is C++ een verouderd paradigma, wat meer en meer hoofdzakelijk voor performance-critical en low-level toepassingen zal worden gebruikt. De performance penalty die C# en Java met zich mee brengen (agv. hogere abstractie, managed code etc.) weegt in veruit de meeste gevallen nauwelijks op tegen de de productiviteitsverhoging die ontwikkeling in laatstgenoemde talen/frameworks met zich meebrengt.

Hoe kan een multi-paradigm language nou een "verouderd paradigma" zijn? C++ ondersteunt juist veel, met name zoals boven al werd gepost generic programming.

[Zoijar]

kenneth schreef op zondag 12 februari 2006 @ 19:36:
[...]
Die volg ik niet
Wat is het verschil tussen C# en C++ hierin?

C#:

List<Customer> foo = new List<Customer>();

C++ ondersteunt echt generic programming. Jouw voorbeeld is niets meer dan "generic types". Het klassieke voorbeeld is dat C++ compile time een reeks van priemgetallen kan berekenen met generics. Het template systeem van C++ is turing compleet, maw het is een volledige taal binnen een taal.

Ie. als voorbeeld, kan je dit in C#?

C++:

template<unsigned int N>
struct fac
{
    enum { value = N * fac<N-1>::value };
};
template<>
struct fac<0>
{
    enum { value = 1 };
};

int main()
{
   // compiles directly as: int  array[120];
    int array[fac<5>::value];
    ...
}

Er is naar mijn weten geen enkele andere mainstream taal die dit kan (op wat academische talen na, die veelal functioneel zijn)
[/code]

[ Voor 32% gewijzigd door Zoijar op 12-02-2006 19:46 ]

[whoami]

flowerp schreef op zondag 12 februari 2006 @ 15:44:
[...]


Is dat zo? Ik bevind me nu enigzins op glad terrein omdat ik al een tijdje geen Windows applicaties meer schrijf, maar ik had juist begrepen dat C# voor ELK Windows programma wat een GUI laat zien (de meerderheid dus) de aangewezen keuze is. Veel mensen willen namelijk niet rechtstreeks tegen de win32 API aan programmeren. Dat is een enorm vervelend karwei gebasseerd op een vrij oud paradigma. -DE- C++ Windows 'API'/wrapper MFC wordt al jaren lang totaal niet meer ontwikkeld. Wil je dus een Windows programma schrijven met gebruik making van de moderne widgets, dan kom je al meteen op .NET uit, en die drukt je toch zeer snel richting C#.

Je hebt ook C++.NET (C++ CLI als ik me niet vergis ? ). Maar het is niet zo dat C# zich enkel voor bedrijfsmatige software waar een db achter zit, leent.
C# is gewoon een all-round taal, waar je heel wat kunt mee doen. Dat je in C# niet rechtstreeks tegen de Win API moet programmeren, is eerder een verdienste van het .NET framework.

C# en Java hebben wel iets wat ze generics noemen en wat kwa naam een beetje doet denken een generic programming. Het is echter iets compleet anders. Feitelijk komt het neer op dat de compiler types kan deduceren en daardoor automatisch casts kan invoegen in code. Kwa gebruik lijkt het wel op een bepaald aspect van generic programming, maar het is echt wat anders.

En wat doet C++ ? De C++ compiler genereert toch at compile time de types die je gebruikt op basis van de template ? In C++ noemt het dan ook geen generics, maar templates dacht ik ?
Bij C# heeft de compiler helemaal niks te zien bij generics. Het is de runtime die voor die specialisatie zorgt.
Bij C# generics kan je constraints definieren, ik denk niet dat dit het geval is in C++ ?

[ Voor 27% gewijzigd door whoami op 12-02-2006 20:40 ]

[flowerp]

whoami schreef op zondag 12 februari 2006 @ 20:28:
Je hebt ook C++.NET (C++ CLI als ik me niet vergis ? ). Maar het is niet zo dat C# zich enkel voor bedrijfsmatige software waar een db achter zit, leent.
C# is gewoon een all-round taal, waar je heel wat kunt mee doen.

Absoluut waar. Wat ik echter bedoelde is dat als je graag met C++ wilt programmeren en een Windows GUI programma wilt maken je een tijd lang weinig keus had. C++ kun je goed gebruiken icm met MFC of win32, maar beiden waren niet echt aan te raden om voor te programmeren. Vroeger was C++ gewoon de aangewezen default taal voor Windows applicaties (vanwege MFC). Nu is C# de aangewezen taal en alleen als de programmeur het heel graag wil zou sinds VS 2005 voor C++ gekozen kunnen worden (maar grote kans dat het bedrijf waar je werk al op C# heeft gestandaardiseerd).

En wat doet C++ ? De C++ compiler genereert toch at compile time de types die je gebruikt op basis van de template ? In C++ noemt het dan ook geen generics, maar templates dacht ik ?

Het paradigma heet generic programming, maar de concrete functie heet template. In echt generic programming heb je zowel een complete compile-time taal tot je beschikking (template meta progamming) als een methode om types te genereren.

In C++ zijn de specialisaties van een template echt aparte types. Map<string> is een ander type als Map<char>. In Java en C# is dat niet zo. De instanceof operator in Java 'vergeet' dan ook de generic typing. Dit kan overigens een voordeel hebben: je hebt maar 1 class definitie aangezien de compiler dus absoluut geen types genereerd maar slechts automatische casts in de bytecode stopt. Als je class definitie veel geheugen in beslag neemt dan zou dit een memory voordeel kunnen zijn.

Via templates kun je ongelooflijk veel dingen doen die je in andere talen eigenlijk alleen via language extensions kan doen. Zo kun je bijvoorbeeld lambda functies maken (zie boost, het is een beetje rare syntax, maar het werkt wel) en ook bijvoorbeeld iets als synchronized op een functie is via templates na te bouwen in C++.

Bij C# generics kan je constraints definieren, ik denk niet dat dit het geval is in C++ ?

De aspects gaan vrij ver in C++09 en daarmee kun je als het goed is dergelijke dingen veel netter en universeler mee doen. Maar goed, dat is C++09 en die is nog -heel ver- weg. Tegen die tijd komt C# ongetwijfeld ook weer met veel nieuws.

[whoami]

flowerp schreef op zondag 12 februari 2006 @ 21:01:
[...]

De aspects gaan vrij ver in C++09 en daarmee kun je als het goed is dergelijke dingen veel netter en universeler mee doen. Maar goed, dat is C++09 en die is nog -heel ver- weg. Tegen die tijd komt C# ongetwijfeld ook weer met veel nieuws.

Zoals lambda expressions bv (C# 3.0). _{Maar nu gaan we offtopic.}

[MSalters]

frickY schreef op zondag 12 februari 2006 @ 14:31:
Ik wist niet dat C++ nog door ontwikkeld wordt, of zou worden?
Ik dacht dat dat bij wijze van spreken 'klaar' was, en C# de opvolger is waar alle tijd in wordt gestoken?

Microsoft's budget voor VC++ is 3x zo groot als dat van C#. Bron: de VP van VC++. Lijkt me dus niet dat Microsoft C++ dood heeft verklaard - en dat is de enige partij die een geloofwaardig alternatief heeft.

[whoami]

Ik denk ook niet dat je C# of Java moet zien als concurrenten voor C++, en al helemaal niet als opvolger.
Er zijn situaties waar C++ de beste taalkeuze is, er zijn situaties waar C#/Java de betere taalkeuze is.

[Verwijderd]

MSalters schreef op zondag 12 februari 2006 @ 21:21:
[...]

Microsoft's budget voor VC++ is 3x zo groot als dat van C#. Bron: de VP van VC++. Lijkt me dus niet dat Microsoft C++ dood heeft verklaard - en dat is de enige partij die een geloofwaardig alternatief heeft.

En die budgetten verbleken waarschijnlijk weer in het licht van de "algemene" .NET-framework gerelateerde ontwikkelings-activiteiten. Feit is natuurlijk dat er nog een enorme groep C++-programmeurs is, welke Microsoft graag diens software ziet aanschaffen.

Zoijar schreef op zondag 12 februari 2006 @ 19:39:
[...]

Ie. als voorbeeld, kan je dit in C#?

C++:

template<unsigned int N>
struct fac
{
    enum { value = N * fac<N-1>::value };
};
template<>
struct fac<0>
{
    enum { value = 1 };
};

int main()
{
   // compiles directly as: int  array[120];
    int array[fac<5>::value];
    ...
}

Dat kan inderdaad niet op die manier in C# (/VB.NET/C++ CLI/etc). Het lijkt me echter vrij ingewikkeld om systemen te onderhouden, waar dit soort constructies serieus in worden toegepast? In C# werk ik met generic classes om m'n code te vereenvoudigen en gedupliceerde logica te vermijden (althans, dat probeer ik ).

[ Voor 21% gewijzigd door Verwijderd op 12-02-2006 23:06 ]

[flowerp]

whoami schreef op zondag 12 februari 2006 @ 21:05:
[...]

Zoals lambda expressions bv (C# 3.0). _{Maar nu gaan we offtopic.}

Nou, ik denk dat dat niet zo heel erg offtopic is. Het punt is dat je met generic programming -ZELF- lambda expressions kunt implementeren. C# 3.0 moet wachten op dat het een ingebouwde taal feature wordt.

Of anders gezegd, met C++ kun je krachtigere, veelzijdigere libraries ontwikkelen op een manier waarop dat in andere talen (nog steeds) niet kan.

Natuurlijk is een ingebouwde taal feature meestal kwa syntax wel makkelijker. Als ik naar boost's lambda expressions kijk dan heb ik nou niet zo iets van, wow, dat ziet er duidelijk uit. Ik wil mischien liever gewoon de normale syntax ervoor gebruiken, maar omdat het een library feature is heb je een rare aparte syntax nodig.

Toch is die enigzins rare syntax een kleine prijs die je betaald voor de bijna ongelimiteerde mogelijkheden. Kijk gewoon eens de Boost library door en zie wat voor dingen je kunt doen als je een taal hebt die zo krachtig is als C++.

[farlane]

-NMe- schreef op zondag 12 februari 2006 @ 17:09:
De oude Borland compiler voor DOS was inderdaad zwaar klote.

Ik weet niet over welke versie jullie het nu hebben, maar ik heb met de V3 DOS compiler behoorlijk veel gewerkt en er was ( voor de stand van zaken van die tijd ) niets mis mee. Met de IDE al helemaal niet, daar kon je als je een paar toetscombinaties kende behoorlijk vlot doorheen. ( En MS had volgens mij helemaal geen IDE in die tijd )

De eerste paar versies van TC voor Windows (3.11?) Waren een hel.

[Olaf van der Spek]

flowerp schreef op zondag 12 februari 2006 @ 14:17:
Stel dat de nieuwe specificatie voor C++ ook in 2008 uitkomt. Het zal dan nog tot 2018 kunnen duren voor de compilers weer compliant zijn. Nu wordt C++ momenteel veel minder gebruikt dan in 1998. Nieuwe Windows applicaties gebruiken vaak C#, server side zie je voornamelijk PHP, C# en Java, embedded zie je C, mobile zie je weer Java, Linux doet bijna alleen C vanwege de "objects are evil philosophy" (die ik zelf niet snap, maar goed), en Mac OS X doet weer voornamelijk objective C voor nieuwe Apps. Alleen in games wordt, als ik het goed heb, nog veel C++ gebruikt.

Het nadeel van C++ ten opzichte van de andere genoemde talen is IMO de beschikbare libraries.
Qua 'taal' is C++ goed, maar aan 'standaard' libraries ontbreekt het een beetje.
Boost is op de goede weg, maar voor veel platform APIs is geen C++ 'wrapper' en al helemaal geen standaard C++ wrapper.

De platformonafhankelijkheid van bijvoorbeeld Java en PHP heeft IMO ook meer te maken met de libraries dan met de bytecode/sourcecode.

[ Voor 13% gewijzigd door Olaf van der Spek op 13-02-2006 12:55 ]

[Zoijar]

OlafvdSpek schreef op maandag 13 februari 2006 @ 12:52:
Het nadeel van C++ ten opzichte van de andere genoemde talen is IMO de beschikbare libraries.
Qua 'taal' is C++ goed, maar aan 'standaard' libraries ontbreekt het een beetje.
Boost is op de goede weg, maar voor veel platform APIs is geen C++ 'wrapper' en al helemaal geen standaard C++ wrapper.

De platformonafhankelijkheid van bijvoorbeeld Java en PHP heeft IMO ook meer te maken met de libraries dan met de bytecode/sourcecode.

Volgens de C++ filosofie hoeven die libraries ook niet standaard te zijn. Als je iets specifieks wilt doen, op een bepaald platform, dan download je toch gewoon een library die dat kan? STL probeert bv ook niet om een container library te zijn, maar stelt tools/componenten beschikbaar om containers te maken. Daarom zit er bv geen graph structuur in de STL, maar die kan je wel maken met vector, list en map.

[Olaf van der Spek]

Zoijar schreef op maandag 13 februari 2006 @ 15:40:
Volgens de C++ filosofie hoeven die libraries ook niet standaard te zijn. Als je iets specifieks wilt doen, op een bepaald platform, dan download je toch gewoon een library die dat kan?

Maar dan is je oplossing niet meer platformonafhankelijk en dat is toch wel erg jammer.

Denk jij dat dit geen nadeel is ten opzichte van talen als Java en PHP?

[Zoijar]

OlafvdSpek schreef op maandag 13 februari 2006 @ 16:35:
Maar dan is je oplossing niet meer platformonafhankelijk en dat is toch wel erg jammer.

Denk jij dat dit geen nadeel is ten opzichte van talen als Java en PHP?

Nou, het idee achter deze beslissing is dat C++ kan draaien op heel uiteenlopende platformen. Bv de rede dat C++ geen gekleurde tekst kan outputten had er mee te maken dat sommige displays monochroom zijn, en je die functionaliteit dus niet kan garanderen op elk platform. Het is voor talen als Java en PHP natuurlijk makkelijker om "platform onafhankelijk" te zijn: ze draaien namelijk feitelijk maar op 1 platform! C++ wil zigch als taal niet vastleggen op specifieke platformen, bv. die hardware locking ondersteunen. als je dat wel wilt, dan moet je een 3rd party library gebruiken. Die kunnen eventueel op meerdere platformen draaien; de taal zelf blijft de grootst gemene deler ondersteunen.

(En ja, ik denk dat te veel componenten opnemen in de standaard alleen maar voor 'bloat' zorgt. Het is al lastig genoeg om het consistent te houden. Je moet geen taal met libraries gaan verwarren, taal en standaard library zijn ook goed gescheiden. En de standaard library bestaat uit generieke componenten, geen volledige implementaties.)

[ Voor 18% gewijzigd door Zoijar op 13-02-2006 17:08 ]

[Olaf van der Spek]

Zoijar schreef op maandag 13 februari 2006 @ 17:04:
(En ja, ik denk dat te veel componenten opnemen in de standaard alleen maar voor 'bloat' zorgt. Het is al lastig genoeg om het consistent te houden. Je moet geen taal met libraries gaan verwarren, taal en standaard library zijn ook goed gescheiden. En de standaard library bestaat uit generieke componenten, geen volledige implementaties.)

Het onderscheid tussen taal, standaard libraries en libraries ken ik wel.
Maar het niet op een standaard manier ondersteunen van features die erg veel platforms wel hebben blijf ik een nadeel vinden.

De reden die je aangeeft vind ik ook niet helemaal kloppen. Als een platform geen kleurendisplays ondersteunt kan het de features die daarmee te maken hebben toch gewoon niet implementeren?
Voor kleurendisplays heb je dan dus optionele features in een library.

Dat Java en PHP een extra platformlaag eisen is waar, maar als die inderdaad beschikbaar is, kiezen veel mensen daar toch voor.

[ Voor 8% gewijzigd door Olaf van der Spek op 13-02-2006 17:24 ]

[Zoijar]

OlafvdSpek schreef op maandag 13 februari 2006 @ 17:22:
De reden die je aangeeft vind ik ook niet helemaal kloppen. Als een platform geen kleurendisplays ondersteunt kan het de features die daarmee te maken hebben toch gewoon niet implementeren?
Voor kleurendisplays heb je dan dus optionele features in een library.

Dus dan heb je een standaard, maar moet je steeds gaan checken of het wel werkt. Doet me erg denken aan de videohardware van een jaar of twee geleden... een drama was dat. "if (!atomic_locking_supported) {std::cerr << "Can't run, no locking!"; exit(1);}" Lijkt me niet echt lekker werken.

[moto-moi]

Zoijar schreef op maandag 13 februari 2006 @ 17:48:
Dus dan heb je een standaard, maar moet je steeds gaan checken of het wel werkt. Doet me erg denken aan de videohardware van een jaar of twee geleden... een drama was dat. "if (!atomic_locking_supported) {std::cerr << "Can't run, no locking!"; exit(1);}" Lijkt me niet echt lekker werken.

Heb je gelijk in, maar het is wel raar dat als je een libary zoekt om (bijvoorbeeld) kleurtjes te gebruiken in de cmdlin dat je dan zelf iets moet gaan maken, of libraries van c moet gaan gebruiken, en ik denk dat OlafvdSpek daarop doelt

[Olaf van der Spek]

Zoijar schreef op maandag 13 februari 2006 @ 17:48:
Dus dan heb je een standaard, maar moet je steeds gaan checken of het wel werkt. Doet me erg denken aan de videohardware van een jaar of twee geleden... een drama was dat. "if (!atomic_locking_supported) {std::cerr << "Can't run, no locking!"; exit(1);}" Lijkt me niet echt lekker werken.

Dat lijkt me eenvoudiger dan tien verschillende interfaces ondersteunen toch?

[ Voor 5% gewijzigd door Olaf van der Spek op 13-02-2006 18:59 ]

[Verwijderd]

flowerp schreef op zondag 12 februari 2006 @ 15:29:
[...]
Nu wil ik Java als taal niet al te veel gaan ophemelen, maar daar werd de nieuwe spec wel degelijk binnen het jaar geimplementeerd door 3rd parties.[...] Eclipse kwam gewoon na 1 jaar met een implementatie en die was dan ook gewoon 100%.

De vergelijking die je hier maakt is niet helemaal eerlijk. De compiler die Eclipse gebruikt (JDT) is slechts een fase 1 compiler. Zoals je mischien weet compileert Java in twee 'fases'. De eerste fase is Java naar intermediate (door sun bytecode genoemt). Dit is een hele simpele transformatie waar ook, volgende de huidige spec, geen optimalisaties gedaan worden. Pas in de 2de fase wordt intermediate (bytecode) naar native gecompileerd, maar dat doet JDT niet.

Tevens implementeerd JDT ook totaal niks van de enorme Java standard library. Het is echt alleen de bare 'front end' compiler. Kijk je naar een echte totale implementatie, dan zie je dat IBM nu een ruime anderhalf jaar na de 5.0 release van Java nog steeds geen 5.0 implementatie heeft (alleen een beta).

In dat licht gezien is het dus nog eigenlijk best lang; 1 jaar over alleen die front end.

[MSalters]

Verwijderd schreef op zondag 12 februari 2006 @ 23:01:
En die (C++) budgetten verbleken waarschijnlijk weer in het licht van de "algemene" .NET-framework gerelateerde ontwikkelings-activiteiten. Feit is natuurlijk dat er nog een enorme groep C++-programmeurs is, welke Microsoft graag diens software ziet aanschaffen.

Het probleem met het "algemene .Net-Framework" budget is dat het niet scherp afgebakend is. Valt .Net Server daaronder? Ook nu het gewoon Server 2003 heet?

Wat betreft de developers: de externe developers zijn aardig, zeker in de grotere enterprise applicaties (veel mensen x dure tools, jammer van de quantumkortingen)maar dat is niet zo belangrijk. VC++2005 Express is niet voor niets gratis.

De kurk van Microsoft zijn het OS, de server spullen en Office. Traditioneel zijn die geheel of gedeeltelijk C++ based. En uiteraard bouwen ze die met VC++. Dus elke % winst die het VC++weet te bereiken in SQL server is 1% extra score op de SQL benchmarks. Elke buffer check die de compiler inbouwt is een stukje defence in depth voor Outlook. De kosten van VC++ worden daarom niet gezien als pure product investments.

[MSalters]

moto-moi schreef op maandag 13 februari 2006 @ 18:49:
[...]
Heb je gelijk in, maar het is wel raar dat als je een libary zoekt om (bijvoorbeeld) kleurtjes te gebruiken in de cmdlin dat je dan zelf iets moet gaan maken, of libraries van c moet gaan gebruiken, en ik denk dat OlafvdSpek daarop doelt

Ik denk het niet - C heeft exact hetzelfde "probleem" met kleurtjes op de command line. Niet zo gek; had C een standaard functie gehad, dan had C++ die naar std:: verhuisd.

Maar uit eigen ervaring kan ik vertellen dat een telefooncentrale weliswaar een commandline heeft, maar dat die zwart-wit is (of wit-zwart, als je de hardcopy output bekijkt ). Toch draait die gewoon K&R C.

[Verwijderd]

Wat mij betreft is C++ nog niet helemaal klaar; ik ben o.m. nog op zoek naar:

- polymorfe recursie
- geparametriseerde types
- geparametriseerde polymorfisme
- generics
- templates
- template specialization
- partial classes
- compile-time reflectie
- property/operator overloading
- checked exceptions
- covariante array-typen
- type casting
- object destructie
- boost static asserts
- anonieme functies
- multi methods
- inner functies
- goto statements
- distributed programming
- Turing computable/compleet
- refactoring
- re-use
- partial specialization

Als dit er allemaal in zit dan ben ik tevreden.

Modbreak:

Gelieve onzin-replies voor jezelf te houden

[ Voor 5% gewijzigd door whoami op 14-02-2006 08:57 ]

[Zoijar]

Verwijderd schreef op dinsdag 14 februari 2006 @ 00:01:
Wat mij betreft is C++ nog niet helemaal klaar; ik ben o.m. nog op zoek naar:

- polymorfe recursie
- geparametriseerde types
- geparametriseerde polymorfisme
- generics
- templates
- template specialization
- partial classes
- compile-time reflectie
- property/operator overloading
- checked exceptions
- covariante array-typen
- type casting
- object destructie
- boost static asserts
- anonieme functies
- multi methods
- inner functies
- goto statements
- distributed programming
- Turing computable/compleet
- refactoring
- re-use
- partial specialization

Als dit er allemaal in zit dan ben ik tevreden.

Zit je nou alleen maar interessant te doen met termen? Een kwart slaat namelijk nergens op, en de helft zit er al lang in.

[MSalters]

OlafvdSpek schreef op maandag 13 februari 2006 @ 17:22:
[...]
Het onderscheid tussen taal, standaard libraries en libraries ken ik wel.
Maar het niet op een standaard manier ondersteunen van features die erg veel platforms wel hebben blijf ik een nadeel vinden.

De reden die je aangeeft vind ik ook niet helemaal kloppen. Als een platform geen kleurendisplays ondersteunt kan het de features die daarmee te maken hebben toch gewoon niet implementeren?
Voor kleurendisplays heb je dan dus optionele features in een library.

Optionele features worden als erg negatief beschouwd. Het voorbeeld waarom is SQL. Dat is weliswaar een standaard, maar omdat je al op de doos "100% SQL standard compliant" mag zetten zodra je de niet-optionele delen hebt geimplementeerd is er weinig incentive geweest om de rest te implementeren. C++ mag dan op 90%+ blijven steken; feitelijk zit SQL op 50%. Daar heb je dan weinig aan, behalve als SQL server verkoper aan PHB's.

Een ander ged voorbeeld is POSIX support in NT 3.51. Vinkje voor de PHB's, geen serieuze developer die het gebruikt.

Sowieso is de console-kleuren library eigenlijk een valse redenering. Zwart-wit displays zijn triviaal te ondersteunen. De lijst met beschikbare kleuren is geen 16M kleuren lang, maar 1. "Kies" maar. Dat kan dus best met een standaard interface. Je ziet ook vrij snel de waarde daarvan. Een vendor die er geen zin in heeft hoeft dus niets. _{(en ANSI color codes zijn wel standaard, dat ANSI heet niet voor niets zo - dus je standaard is er al, alleen achter C++ om)}

Tenslotte valt of staat alles met de bereidwilligheid van vendors. Dat is een vrij directe functie van marktvraag. Kleurtjes in de console is geen vraag van de partijen die geld overhebben voor C++ compilers. En nee, de mensen die de gratis compiler downloaden tellen niet even zwaar.

[Olaf van der Spek]

MSalters schreef op dinsdag 14 februari 2006 @ 00:07:
Optionele features worden als erg negatief beschouwd. Het voorbeeld waarom is SQL. Dat is weliswaar een standaard, maar omdat je al op de doos "100% SQL standard compliant" mag zetten zodra je de niet-optionele delen hebt geimplementeerd is er weinig incentive geweest om de rest te implementeren. C++ mag dan op 90%+ blijven steken; feitelijk zit SQL op 50%. Daar heb je dan weinig aan, behalve als SQL server verkoper aan PHB's.

Waar staat PHB voor?
En het alternatief is toch dat elke vendor features op een vendor specefieke manier implementeerd? Dat lijkt me nog negatiever.

Een ander ged voorbeeld is POSIX support in NT 3.51. Vinkje voor de PHB's, geen serieuze developer die het gebruikt.

SATA2 is ook een leuke.

Kleurendisplays was maar een simpel voorbeeld, je begrijpt hopelijk wat ik bedoel.
Hmm, marktvraag.

[Verwijderd]

Verwijderd schreef op dinsdag 14 februari 2006 @ 00:01:
Wat mij betreft is C++ nog niet helemaal klaar; ik ben o.m. nog op zoek naar:

- polymorfe recursie
- geparametriseerde types
- geparametriseerde polymorfisme
- generics
- templates
- template specialization
- partial classes
- compile-time reflectie
- property/operator overloading
- checked exceptions
- covariante array-typen
- type casting
- object destructie
- boost static asserts
- anonieme functies
- multi methods
- inner functies
- goto statements
- distributed programming
- Turing computable/compleet
- refactoring
- re-use
- partial specialization

Als dit er allemaal in zit dan ben ik tevreden.

Begin eens met het lezen van een eenvoudig introductie boek over C++. Dan kom je er achter dat je al veel kunt doorstrepen van dit lijstje.

[.oisyn]

Interessante draad. Ook ik zit te wachten op een nieuwe revisie, en die lijkt idd behoorlijk ver weg (ze hopen die 0 in C++0x iig een 0 te laten blijven). Maar ik denk niet dat het daarna ook nog eens lang wachten wordt op de compilers. EDG zal iig wel snel met een reference implementatie komen, die door een aantal grote vendors (waaronder Intel geloof ik?) wordt gebruikt. Comeau blijft natuurlijk ook niet achter, en ook gcc zal wel snel een werkende implementatie hebben.

De grote speler die tot voor kort (lees: tot een jaar of 3 geleden) behoorlijk achter liep was Microsoft. Tot voor kort, want hun visie op standard complianceness is in de loop der jaren behoorlijk veranderd. Ook zij zien in wat voor waarde een conformante compiler heeft bij de C++ developer, en ik denk dan ook niet dat we nog eens 8 jaar moeten wachten voordat ook zij met een redelijke C++0x compiler komen. Zeker als je ziet wat voor werk ze in C++/CLI hebben gestoken door dat te standaardizeren en de prominente C++ers erbij te betrekken.

---

Verder wat reacties over bepaalde opmerkingen die ik in deze draad ben tegen gekomen:
[list]• het maken van GUI apps is natuurlijk voornamelijk een library-iets (met een goede library en IDE ondersteuning kun je in C++ net zo RAD ontwikkelen als in C# of Delphi)
• Borland heeft overigens onlangs bekend gemaakt z'n IDE devisie te willen verkopen (en dat betekent dus alle IDEs die ze in huis hebben), en zich idd te willen richten op lifecycle tools.
• Qt is geen C++ maar een superset ervan (voor een discussie klik hier).
• Templates, en specifiek Zoijar's code zoals geplaatst in deze draad, werken gewoon onder C++/CLI, itt wat vieux zegt . Is ook niet zo vreemd want het is een compile-time iets, dus van de templates zelf is al niets meer te zien na het compileren naar de .Net IL (je komt alleen wel in de knoei met publieke symbols in de assemblies, maar daar heb je sowieso niets aan aangezien andere talen geen templates kennen)

[ Voor 9% gewijzigd door .oisyn op 14-02-2006 15:16 ]

[Zoijar]

.oisyn schreef op dinsdag 14 februari 2006 @ 15:11:
De grote speler die tot voor kort (lees: tot een jaar of 3 geleden) behoorlijk achter liep was Microsoft. Tot voor kort, want hun visie op standard complianceness is in de loop der jaren behoorlijk veranderd. Ook zij zien in wat voor waarde een conformante compiler heeft bij de C++ developer, en ik denk dan ook niet dat we nog eens 8 jaar moeten wachten voordat ook zij met een redelijke C++0x compiler komen. Zeker als je ziet wat voor werk ze in C++/CLI hebben gestoken door dat te standaardizeren en de prominente C++ers erbij te betrekken.

Verder is het volgens mij ook nog zo dat compilers als Comeau, en uiteraard libraries als Boost, alle nieuwe voorstellen meteen implementeren in een soort van extended beta versie (of dat een nieuw voorstel naar voren komt nav juist een beta functionaliteit). Het zal me dan ook niets verbazen als direct na het officieel vastleggen van C++0x het een race is wie de eerste compliant compiler op de markt heeft; een race waarbij sommige deelnemers de finish lijn al in zicht hebben voordat de race begint. Ik denk dat er binnen een jaar een of meerdere compilers de volledige nieuwe standaard ondersteunen.

[MSalters]

OlafvdSpek schreef op dinsdag 14 februari 2006 @ 08:36:
[...]
Waar staat PHB voor?
En het alternatief is toch dat elke vendor features op een vendor specefieke manier implementeerd? Dat lijkt me nog negatiever.

Dilbert term, Pointy-Haired Boss.

Je vergeet even dat in het geval van een optionele standaard die genegeerd wordt, de vendors nog steeds alle features op een specifieke manier implementeren. Dus in plaats van N manieren om iets te doen heb je N+1 manieren. Geen winst, en het maken van een standaard wordt er wel complexer op.

[MSalters]

Zoijar schreef op dinsdag 14 februari 2006 @ 15:50:
[...]
Verder is het volgens mij ook nog zo dat compilers als Comeau, en uiteraard libraries als Boost, alle nieuwe voorstellen meteen implementeren in een soort van extended beta versie (of dat een nieuw voorstel naar voren komt nav juist een beta functionaliteit). Het zal me dan ook niets verbazen als direct na het officieel vastleggen van C++0x het een race is wie de eerste compliant compiler op de markt heeft; een race waarbij sommige deelnemers de finish lijn al in zicht hebben voordat de race begint. Ik denk dat er binnen een jaar een of meerdere compilers de volledige nieuwe standaard ondersteunen.

Comeau maakt eigenlijk geen compilers, het is gewoon Greg die bij EDG een frontend inkoopt, bij Dinkumware een STL en die vervolgens customized. De standaard C backends voor MSVC/GCC/etc zijn behoorlijk stabiel, vandaar dat die zo goedkoop zijn.

En EDG is redelijk nauw betrokken bij nieuwe features. Sterker nog, als een willekeurige EDG medewerker zegt dat een feature niet kan, dan is dat feature daarmee feitelijk van de baan.

De finish lijn is uiteraard ruim op tijd in zicht. Sterker nog, in tegenstelling tot 1998 is er nu weinig intern spectaculairs. Iedereen weet hoe elk voorstel kan worden geimplementeerd. Dat het resultaat de moeite waard is, komt meer omdat we na 8 jaar C++'98 nu snappen hoe de taal gebruikt moet worden, en er dus slimmer nieuwe features toegevoegd kunnen worden. Zoiets als boost bestond simpelweg niet in 1994.

[Olaf van der Spek]

MSalters schreef op dinsdag 14 februari 2006 @ 23:20:
Je vergeet even dat in het geval van een optionele standaard die genegeerd wordt, de vendors nog steeds alle features op een specifieke manier implementeren. Dus in plaats van N manieren om iets te doen heb je N+1 manieren. Geen winst, en het maken van een standaard wordt er wel complexer op.

Maar waarom zouden vendors de standaard negeren en het toch op een specifieke manier implementeren?
Natuurlijk kan het voorkomen, maar ik zou toch aannemen dat het aantal manieren daalt inplaats van stijgt.

[Daos]

Dat er zoveel problemen waren rond C++ komt doordat de standaard te laat kwam. Veel compilerbouwers hadden al een C++-compiler met libraries gemaakt voordat de standaard er was. Het gevolg was dat veel dingen net iets anders gingen dan bij de concurrenten en de latere standaard.
Hetzelfde verschijnsel zie je ook bij de draadloze netwerken. Al voordat een standaard goedgekeurd is, wordt de markt al overspoelt met producten die ongeveer hetzelfde doen.

Een nieuwe versie van C++ is volgens mij al nodig als een compilerbouwer iets nuttigs toevoegt. De nieuwe versie moet er dan komen voordat de concurrenten iets soortgelijks implementeren.


Zelf mis ik niet veel dingen in C++. Het enige dat ik kan bedenken is een library met vector en matrix functies die op een PC gebruik maakt van MMX/SSE en het opnemen van POSIX in de standaard.

Het is jammer dat de Informatica (net als bv de media) last heeft van hypes. Voorbeelden hiervan zijn XML, Regular Expressions en Generics.
Zonder die dingen kan je nog steeds makkelijk een programma maken. Zonder Regular Expressions en Generics is het volgens mij zelfs een stuk overzichtelijker.

[.oisyn]

Daos schreef op woensdag 15 februari 2006 @ 10:38:
Zelf mis ik niet veel dingen in C++. Het enige dat ik kan bedenken is een library met vector en matrix functies die op een PC gebruik maakt van MMX/SSE

Die kun je zelf makkelijk maken. Wij gebruiken in onze games ook een dergelijke libraries die gebruik maken van sse intrinsics. Met de compilers van microsoft (x86 voor PC en Xbox, PPC voor Xbox360) kun je een optimalisatiepath triggeren door gewoon zo'n vector register in een class te wrappen en gebruik te maken van de juiste intrinsic functies. Mooie C++ code als 3.f * (v1 + v2) * m compileert dan direct naar de juiste vector machinecode

Het is jammer dat de Informatica (net als bv de media) last heeft van hypes. Voorbeelden hiervan zijn XML, Regular Expressions en Generics. Zonder die dingen kan je nog steeds makkelijk een programma maken. Zonder Regular Expressions en Generics is het volgens mij zelfs een stuk overzichtelijker

Kom op, regular expressions vormen de basis voor compilerbouw, en generics maken je het leven als programmeur een stuk makkelijker op. Natuurlijk heb je ze niet nodig, maar volgens diezelfde redenatie kun je ook in assembly gaan programmeren. Het feit dat het gehyped wordt en elke idioot het te pas en te onpas wil gebruiken (net als bij design patterns, ook zoiets) wil nog niet zeggen dat ze meteen maar compleet genegeerd moeten worden door de professionele developers.

Of zou jij het handig vinden om moeilijk te gaan doen met allerlei custom operaties op een string om iets te vinden, terwijl je dat in 5 seconden ingetypt zou hebben met een regex. Of continu te casten en dus typesafety weg te gooien elke keer als je iets uit een container haalt, omdat je geen gebruik wilt maken van generics?

Wat ik graag nog zou willen zien, afgezien van de obvious dingen als een template typedef, een typeof operator en een null keyword, is meer metaprogramming (zoals: bestaat deze identifier of member?) en betere runtime type information (iets wat een beetje in de buurt komt van de reflection libraries van Java en .Net) en fatsoenlijke lambda expressions (en niet die halfbakken boost::lambda)

[seamus21]

FF offtopic vraagje.

Kan je met C# grafisch hetzelfde als C++

Ik bedoel als ik fullscreen apps (kleine games) mbv directx of opengl wil maken is een van de twee dan een betere keus of haalt dit niet zoveel uit. Waarschijnlijk kan je met beide talen dezelfde grafische biebs aanspreken maar misschien zijn er mensen die bij een van de twee tefgen bepaalde zaken zijn aangelopen waardoor de ander net handiger is?

[ Voor 32% gewijzigd door seamus21 op 15-02-2006 11:50 ]

[Olaf van der Spek]

.oisyn schreef op woensdag 15 februari 2006 @ 11:36:
Die kun je zelf makkelijk maken. Wij gebruiken in onze games ook een dergelijke libraries die gebruik maken van sse intrinsics.

Het probleem met die aanpak (dat kan je zelf maken) is dat code delen een stuk lastiger wordt.
Als je 10 stukken code hebt en elk stuk gebruikt bijvoorbeeld een andere string implementatie dan wordt het er niet eenvoudiger op.

[Daos]

.oisyn schreef op woensdag 15 februari 2006 @ 11:36:
Kom op, regular expressions vormen de basis voor compilerbouw,
...
Of zou jij het handig vinden om moeilijk te gaan doen met allerlei custom operaties op een string om iets te vinden, terwijl je dat in 5 seconden ingetypt zou hebben met een regex.

Regular expressions worden alleen in de compiler gebruikt om aan te geven hoe de tokens er uitzien. Dat stelt niet zoveel voor. Bv:

code:

IDENTIFIER     [A-Za-z_][A-Za-z_0-9]*

DEC_CONST      [1-9][0-9]*
HEX_CONST      0[Xx][0-9A-Fa-f]+
OCT_CONST      0[0-7]*
INTEGER_CONST  {DEC_CONST}|{HEX_CONST}|{OCT_CONST}

Het maken van regular expression gaat misschien sneller dan een paar regels code, maar een regular expression is moeilijk te debuggen of uit te breiden. Dit is vooral een groot probleem als hij niet van jou is of als je hem een tijdje terug hebt gemaakt.

generics maken je het leven als programmeur een stuk makkelijker op. Natuurlijk heb je ze niet nodig, maar volgens diezelfde redenatie kun je ook in assembly gaan programmeren. Het feit dat het gehyped wordt en elke idioot het te pas en te onpas wil gebruiken (net als bij design patterns, ook zoiets) wil nog niet zeggen dat ze meteen maar compleet genegeerd moeten worden door de professionele developers.
...
Of continu te casten en dus typesafety weg te gooien elke keer als je iets uit een container haalt, omdat je geen gebruik wilt maken van generics?

Dat de cast niet meer nodig is, is een klein voordeel.

Ik zie echter vaak dat mensen teveel met generics doen. Zeker de laatste tijd nu het weer een hype begint te worden (Een paar jaar geleden was er een hype met Perl.).

Zit het niet in de taal, dan heb je ook geen last van. Hetzelfde geldt ook voor de goto.

[.oisyn]

OlafvdSpek
Een string type heb je vrijwel altijd nodig, een vector type niet. En zeker als je het hebt over SSE optimalisaties, want dan beperk je je sowieso al tot vectoren met maximaal 4 componenten. Een generieke library zou een vector type moeten ondersteunen met een arbitrair aantal componenten en een willekeurig scalar type (float, double, complex, etc.). De operaties zijn dan ook generiek, de enige zekerheid die je hebt is dat het een vector space is, dus dat er een optelling, een additieve inverse en een vermenigvuldiging met een scalar bestaat, maar meer ook niet. En meestal wil je veel meer dan die paar operaties, maar dat komt omdat je weet in wat voor space jij werkt en welke operaties dus wiskundig mogelijk zijn. Dus nee, ik denk dat een generieke library niets opschiet.

[whoami]

Regexen zijn zowiezo handig als je input validatie moet doen. Bv, nagaan of een telefoonnr een geldig formaat heeft.

Generics zijn ook gewoon handig en nuttig. Het biedt je in 't geval van collections bv typed collections, waardoor bepaalde fouten al door de compiler ontdekt kunnen worden.
In .NET kan het er ook voor zorgen dat je minder box/unbox operaties hebt.
(wat oisyn al min of meer zegt dus eigenlijk)

[.oisyn]

Daos schreef op woensdag 15 februari 2006 @ 12:25:
[...]

Regular expressions worden alleen in de compiler gebruikt om aan te geven hoe de tokens er uitzien. Dat stelt niet zoveel voor. Bv:

Je hebt zeker nog nooit een vak als compilerbouw gevolgd op een hogeschool of universiteit?

Het maken van regular expression gaat misschien sneller dan een paar regels code, maar een regular expression is moeilijk te debuggen of uit te breiden. Dit is vooral een groot probleem als hij niet van jou is of als je hem een tijdje terug hebt gemaakt.

Kom dan eens met een voorbeeld waar je typisch gebruik zou maken van reguliere expressies, zonder gebruik te maken van reguliere expressies, en toon aan dat dat wél duidelijk en makkelijk te debuggen is.

Overigens kun je reguliere expressies ook gewoon als grammatica-notatie definieren, dan wordt het al een stuk leesbaarder.

Dat de cast niet meer nodig is, is een klein voordeel.

Je snapt het niet. Het feit dat die cast uberhaupt nodig is wil zeggen dat je typeinformatie -en dus safety- verliest. Neem de originele Vector class uit Java voordat generics aan java toegevoegd werden. Je wilt dat er alleen maar Strings ingestopt worden, maar iedereen stopt er fijn compleet andere objecten in. Dat mag, je krijgt immers geen compile error als je het doet. Als het runt gaat het vervoglens gruwelijk fout als de code die die vector gebruikt wel de aanname maakt dat er alleen maar strings in zitten. Runtime fouten zijn per definitie lastiger dan compile-time fouten, omdat je van een compile-time fout direct op de hoogte wordt gebracht. Bij een run-time fout moet je maar net de mazzel hebben dat hij optreedt en je ervan op de hoogte wordt gesteld.

Een tegenovergesteld voorbeeld is de String. Die is in Java per definitie niet generiek aangezien er alleen maar chars in kunnen zitten, en dat terwijl een 'string' gewoon een tekenreeks is, en alle gangbare operaties hetzelfde zijn ongeacht het soort teken dat je erin stopt. In Java zit je vast aan een char, je kunt geen custom type maken dat een enkel teken voorstelt, en daar een string omheen bouwen. Kan wel, maar dan moet je de hele String class dupliceren, inclusief alle operaties die erop werken. In C++ heb je daar geen last van, een std::basic_string is generiek en werkt ongeacht het type van een enkel teken. Meestal gebruik je std::string wat een typedef is voor de basic_string met char, of een wstring voor een wchar_t, maar niets weerhoudt je ervan om een eigen teken-type te introduceren, zoals JapaneseChar, en daar een basic_string<JapaneseChar> van te vormen. En zonder extra werk heb je meteen zoek-operaties, en met boost::regex kun je er zelfs regular expressions op los laten. Moet je met Java eens proberen.

Ik zie echter vaak dat mensen teveel met generics doen. Zeker de laatste tijd nu het weer een hype begint te worden (Een paar jaar geleden was er een hype met Perl.).

Ik heb het idee dat je teveel kijkt naar hoe de populatie ermee omgaat, ipv echt te kijken naar of een feature nuttig is of niet.

[ Voor 35% gewijzigd door .oisyn op 15-02-2006 13:06 ]

[GrimaceODespair]

Daos schreef op woensdag 15 februari 2006 @ 12:25:
[...]

Regular expressions worden alleen in de compiler gebruikt om aan te geven hoe de tokens er uitzien. Dat stelt niet zoveel voor.

[...]

Het maken van regular expression gaat misschien sneller dan een paar regels code, maar een regular expression is moeilijk te debuggen of uit te breiden. Dit is vooral een groot probleem als hij niet van jou is of als je hem een tijdje terug hebt gemaakt.

Wat dacht je van datavalidatie? Sorry, maar voor mij betekent "moeilijk leesbaar" niet onbruikbaar. Zolang je maar duidelijk ontwerpt en documenteert, mag dit toch geen obstakel zijn? En wat betreft debuggen: bij regex'en komen unit tests daar erg handig bij van pas.

[...]

Dat de cast niet meer nodig is, is een klein voordeel.

Ik zie echter vaak dat mensen teveel met generics doen. Zeker de laatste tijd nu het weer een hype begint te worden (Een paar jaar geleden was er een hype met Perl.).

Zit het niet in de taal, dan heb je ook geen last van. Hetzelfde geldt ook voor de goto.

Generics is iets dat ik enorm mis in .NET 1.x. Typesafety is een feature die je een hoop kopzorgen, en vaak ook werk bespaart.

Het is nogal gezegd: omdat anderen een feature misbruiken, betekent nog niet dat hij overbodig of onnodig is.

[EfBe]

.oisyn schreef op woensdag 15 februari 2006 @ 12:53:
[...]
Je hebt zeker nog nooit een vak als compilerbouw gevolgd op een hogeschool of universiteit?

Volgens mij ben jij in de war met (E)BNF notaties en lex code. Een lexical analyzer werkt gewoon met state machines en het is 'makkelijker' deze te definieren in (E)BNF middels regexps. Zelf een lexical analyzer maken is overigens ook simpeler met regexps daar de code die regexp matching doet veelal dit doet middels de state machines die je anders had moeten implementeren.

Dus: het is makkelijker met regexps, omdat de taaltjes voor de syntaxis deze ondersteunen, maar nodig zijn ze allerminst.

Over generics:
Het nut van generics wordt soms sterk overdreven, vooral in talen waarbij er geen operator overloads te definieren zijn voor generic code en / of waarbij je bij het specificeren van een generic method geen hints/restricties kunt opgeven voor overloaded/supported operators in T.

Het punt is nl, dat generic collections op zich erg nuttig zijn, maar dat het gebruik in code waarbij je NIET het type van T weet meteen een probleem schept. Men gaat dan die code OOK generiek maken, maar ooit moet je T specificeren anders compileert het niet. Dit is op te lossen met interfaces die niet generic zijn, en die meteen aangeven dat je ook generiek kunt programmeren zonder generics, nl. gewoon met interfaces.

[ Voor 35% gewijzigd door EfBe op 15-02-2006 13:16 ]

[.oisyn]

EfBe schreef op woensdag 15 februari 2006 @ 13:12:
[...]

Volgens mij ben jij in de war met (E)BNF notaties en lex code.

Nee, ik denk eerder dat Daos daarmee in de war is.

[Olaf van der Spek]

.oisyn schreef op woensdag 15 februari 2006 @ 12:28:
OlafvdSpek
Een string type heb je vrijwel altijd nodig, een vector type niet. En zeker als je het hebt over SSE optimalisaties, want dan beperk je je sowieso al tot vectoren met maximaal 4 componenten.

Het was bedoeld als algemene opmerking. Op SSE is het inderdaad minder van toepassing, maar kijk bijvoorbeeld naar std::string vs MFC CString. Verschillende (file/socket) descriptor wrappers, thread support, dat soort dingen.

.oisyn schreef op woensdag 15 februari 2006 @ 12:53:
Je hebt zeker nog nooit een vak als compilerbouw gevolgd op een hogeschool of universiteit?

Ik wel, maar ook ik kan me toch even niet meer herinneren waar ze dan nog meer gebruikt worden.

[ Voor 22% gewijzigd door Olaf van der Spek op 15-02-2006 14:15 ]

[Daos]

.oisyn schreef op woensdag 15 februari 2006 @ 12:53:
[...]

Je hebt zeker nog nooit een vak als compilerbouw gevolgd op een hogeschool of universiteit?

Jawel. Ik ben die regular expressions alleen tegengekomen in de "token description" bij het maken van de lexical analyser. De "language grammar" voor de parser werd opgeschreven in BNF (recursief taaltje).

Compiler:

                               program text
                            ________|_________
                           /       \|/        \
token       -> scanner   ->| lexical analysis |
description    generator   |        |         |
                           |        | tokens  |
                           |       \|/        |
language    -> parser    ->| syntax analysis  |
grammar        generator   |        |         |
                           |        | AST     |
                           |       \|/        |
                           | context handling |
                           \________|_________/
                                   \|/        
                              annotated AST
                            ________|_________
                           /       \|/        \
                           | code generation  |
                           \________|_________/
                                   \|/        
                                  code

Kom dan eens met een voorbeeld waar je typisch gebruik zou maken van reguliere expressies, zonder gebruik te maken van reguliere expressies, en toon aan dat dat wél duidelijk en makkelijk te debuggen is.

PHP:

// get host name from URL 
preg_match("/^(http:\/\/)?([^\/]+)/i", 
   "http://www.php.net/index.html", $matches); 
$host = $matches[2]; 

// get last two segments of host name 
preg_match("/[^\.\/]+\.[^\.\/]+$/", $host, $matches); 
echo "domain name is: {$matches[0]}\n";

Zonder regular expressions doe je zoiets:

code:

Stap1: Zoek vanaf links "http://"
Stap2: Zoek vanaf links "/"
Stap3: Pak het tussenstuk

Met tussenstuk:
Stap1: Zoek vanaf rechts het tweede "."
Stap2: Pak het eindstuk

[.oisyn]

Dat is idd een simpel voorbeeld, maar ga nu maar eens een C++ getal als string valideren, oftewel één of meer digits, gevolgd door een optionele punt en nul of meer digits, gevolgd door een optionele 'e' met een optioneel teken en één of meer digits, gevolgd door een optionele 'f'. Als regex is dat simpelweg

code:

^\d+(\.\d*)?([eE][+\-]?\d+)?[fF]?$

Wat het eerste stuk betreft: laat maar, ik heb het idee dat we langs elkaar heen praten.

[Zoijar]

Ten eerste, waar en wanneer je regexes nodig hebt in een compiler hangt compleet van de taal en compiler af. Regex zegt het al, het definieert een reguliere grammatica/taal. Als je taal zelf regulier is kan je alles met regexen doen, maar veel talen zijn context sensitive. Dan kan je andere parsers gebruiken, waar verschillende soorten van zijn; wat een off topic dicussie is... Aangezien C++ templates turing compleet zijn, kan je er regexen in implementeren

Ten tweede is er een wezenlijk theoretisch verschil tussen talen die kwantificatie over types toestaan (C++ templates), en die dat niet doen. De eerste zijn equivalent met 2e orde logica. Als ik heel eerlijk ben weet ik niet meer precies welke met welke equivalent zijn, en welke wat voortbrengt... dus als je interesse hebt, zoek het dan even op: typed lambda calculus, 2nd order predicate logic, quantification over types.

[Daos]

.oisyn schreef op woensdag 15 februari 2006 @ 15:48:
Dat is idd een simpel voorbeeld, maar ga nu maar eens een C++ getal als string valideren, oftewel één of meer digits, gevolgd door een optionele punt en nul of meer digits, gevolgd door een optionele 'e' met een optioneel teken en één of meer digits, gevolgd door een optionele 'f'. Als regex is dat simpelweg

code:

^\d+(\.\d*)?([eE][+\-]?\d+)?[fF]?$

Maar even in C:

C:

#include <ctype.h>

int main() {
    char *test = "0.1234E-56f";

    int match = 1;


    /* \d+ */
    if (isdigit(* test))
        test ++;
    else
        match = 0;
    while(isdigit(* test))
        test ++;


    /* (\.\d*)? */
    if ('.' == * test) {
        test ++;

        while(isdigit(* test))
            test ++;
    }

    /* ([eE][+\-]?\d+)? */
    if ('e' == * test || 'E' == * test) {
        test ++;

        if ('+' == * test || '-' == * test)
            test ++;

        if (isdigit(* test))
            test ++;
        else
            match = 0;
        while(isdigit(* test))
            test ++;
    }

    /* [fF]? */
    if ('f' == * test || 'F' == * test)
        test ++;


    if (* test != 0)
        match = 0;


    printf("match = %s\n", match?"true":"false");

    return 0;
}

De hoeveelheid werk viel inderdaad een beetje tegen. En ik heb regular expressions moeten gebruiken als commentaar om het engszins leesbaar te houden.

Het is dus toch wel handig.

[ Voor 7% gewijzigd door Daos op 15-02-2006 16:47 ]

[Zoijar]

Ik zou trouwens graag native vector support zien ... het blijft lastig werken met al die template vector libraries... Hoewel Blitz++ wel aardig in de buurt komt. UBlas heeft dan weer alleen interface en geen funcionaliteit... Dus een toevoeging van native slicing en ranges zou handig zijn. Vergelijk bv maar hoe makkelijk het programmeert in Matlab vs C++.

[Verwijderd]

OlafvdSpek schreef op woensdag 15 februari 2006 @ 12:13:
[...]
Het probleem met die aanpak (dat kan je zelf maken) is dat code delen een stuk lastiger wordt.
Als je 10 stukken code hebt en elk stuk gebruikt bijvoorbeeld een andere string implementatie dan wordt het er niet eenvoudiger op.

Voor alle duidelijkheid, dit is dus historisch inderdaad gebeurd. Voordat std::string er was, had zo'n beetje elke toolkit, framework, library, api, platform of wat dan ook z'n eigen string implementatie. Een bekend voorbeeld is de CString van MFC, maar er waren velen, velen anderen.

.oisyn schreef op woensdag 15 februari 2006 @ 12:53:
[...] Neem de originele Vector class uit Java voordat generics aan java toegevoegd werden. Je wilt dat er alleen maar Strings ingestopt worden, maar iedereen stopt er fijn compleet andere objecten in. Dat mag, je krijgt immers geen compile error als je het doet. Als het runt gaat het vervoglens gruwelijk fout [...]

Inderdaad. Het is moeilijk om te begrijpen waarom de designers van Java niet meteen vanaf het begin Generics in de taal gestopt hebben. De techniek was toen al bekend van C++. Het is werkelijk ongehoord dat een taal die zo pretendeerde (type-)safe te zijn, zo'n gruwelijke ommissie zo lang heeft kunnen doen voortbestaan. Eigenlijk kun je stellen dat in een goed design, binnen je object wereld, casts eigenlijk nooit nodig hoeven te zijn. Alleen als je heel erg low-level werkt in C++ (bv directe hardware/memory access) dan zou de cast nodig zijn.

In pre 5.0 Java was elke meest triviaal stukje business code doorspekt van casts. En dan bedoel ik niet hier en daar eentje maar werkelijk bijna op elke regel. Generics zijn dus een integraal onderdeel van je type systeem. Het is geen hype, maar IMHO een vereist iets in een strong-typed taal.

Generics zijn daarbij ook nog eens heel practisch. In het verlengde van een foute aanname doen over de type in een collection is er nog de taak om uit te vinden WAT er uberhaupt in een collection zit. Een functie die een raw type List terug geeft in Java en niet in de doc duidelijk zegt wat er IN die list zit is heel moeilijk te gebruiken, helemaal als je geen source hebt. Heb je de source dan is het nog moeilijk, want dan moet je die gaan doorzoeken op inserts in die collection. Eigenlijk voel ik me altijd een beetje stom als ik zoiets aan het opzoeken ben.

Als praktijk voorbeeld, toevallig vandaag nog met een legacy stukje code gewerkt in Java: HashMap getAnnotatedStateGroups(); geen idee dus wat precies het type was en de key. Na een tijdje zoeken bleek er dus een Integer key gebruikt te worden en een List value. Dan weet je nog niks, want dan moet je weer tig code files doorspitten om te zien wat de list bevat. Dat bleek dus in dit geval een State te zijn. Had die method de signature HashMap< Integer, List<Group> > getAnnotatedStateGroups(); gehad, dan had ik dit METEEN gezien. Als je dergelijke dingen 10x per dag tegenkomt dan begrijp je dat ook in dit opzicht Generics alles behalve een overbodige luxe zijn.

[MSalters]

Zoijar schreef op woensdag 15 februari 2006 @ 18:37:
Ik zou trouwens graag native vector support zien ... het blijft lastig werken met al die template vector libraries... Hoewel Blitz++ wel aardig in de buurt komt. UBlas heeft dan weer alleen interface en geen funcionaliteit... Dus een toevoeging van native slicing en ranges zou handig zijn. Vergelijk bv maar hoe makkelijk het programmeert in Matlab vs C++.

std::valarray? Dat ding heeft twee problemen: niet iedereen optimized even goed (een probleem wat breder is, dat geldt voor bijna elke class in elke populaire taal) en de commissie weet noet precies wat de markt wil. Als je een helder idee hebt hoe std::valarray beter kan, dan wordt een paper gewaardeerd.