[c++] Waarom -nog- steeds geen 100% standard conformance?

[flowerp]

Ik vroeg me af of er hier iemand is die weet waarom er nu, een goede 6 jaar na het uitkomen van de standaard, nog steed geen compiler is die helemaal 100% C++ implementeerd. Ik begrijp dat een compiler bouwen geen eitje is, maar voor 1998 bestonden ook al C++ compilers die toch al behoorlijk ver waren.

Is het nu zo dat de heren compiler bouwers echt al 6 jaar lang dag en nacht lopen te ploeteren om de features erin te krijgen die nog missen? Ik kan me dat eigenlijk bijna niet voorstellen. Of is het meer zo dat er een weekje aan gewerkt wordt, dan weer 1 jaar gewacht op beslissingen van commitee's enz, dan weer een weekje programmeren, en dat dat de reden is dat het zo lang duurt.

Als je bv naar Java kijkt, dan zal je zien dat de compiler en de eerste nieuwe taal standaard (Java 5.0) tegelijk zullen verschijnen. Met C# zie je het zelfde, echter met C99 weer niet. Zou je dus daar mischien uit kunnen concluderen dat een taal standaard wel in handen van een (groot) bedrijf moet zijn wil het niet 10 jaar duren voor een standaard in een concreet produkt omgezet wordt?

Tevens, wat zijn hier de meningen over hoe lang het nog zou duren voor er wel een 100% standaard C++ compiler is? Als ik zo naar de huidige progress kijk en de regel gebruik dat de laatste paar procentjes het zwaarste wegen, dan gok ik heel voorzichtig op nog een jaar of 4, mischien zo'n +- 2 jaar voor de opvolger van de huidige C++ standaard zal komen (die schat ik nu op zo rond 2010). Beiden jaar tallen zijn redelijk natte vinger werkt overigens.

Wat denken jullie?

[Soultaker]

Ik weet alleen dat ik zelf al jarenlang in C++ programmeer, de meeste functionaliteit in de praktijk wel aan de praat krijg en vrijwel alles wat ik wil schrijven in werkbare C++ code om kan zetten. Toch gebeurt het me regelmatig dat ik hier op GoT een C++-topic voorbij zie komen waar code in voorkomt die ik niet volledig kan ontleden. Dan komt er meestal iemand als MSalters of .oisyn langs om te vertellen hoe het echt zit.

Ik concludeer hier uit dat C++ een taal is die redelijk logisch in elkaar zit, maar in totaliteit erg complex is. Net zoals het goed mogelijk is om de taal voor 90% te kennen, denk ik dat het goed mogelijk om een 90% standard compliant compiler te schrijven. 100% compliance is door de complexiteit van de taal echter erg lastig; zowel voor een programmeur als een compiler writer.

Daarbij helpt het natuurlijk ook niet dat de specificaties steeds aangepast werden. Ik kan me voorstellen dat het erg lastig om een compiler van voor 1998 zo aan te passen dat 'ie opeens standard compliant wordt. Je moet dan heel precies weten wat er allemaal veranderd is.

Ik weet trouwens niet echt hoe je standard compliance moet meten. Ik denk dat er altijd nog wel ambiguïteiten in de standaard zullen zitten net zoals er altijd kleine fouten in C++ compilers zullen zitten. Wachten op de perfecte C++ compiler is als wachten op een foutloos besturingssysteem; daar kun je dus lang op wachten.

[farlane]

Ik vraag me ook af of het wel zinnig is om die laatste paar procenten aan conformiteit in je compiler te maken, als het zonder al sinds 1998 met veel success wordt gebruikt.

[flowerp]

Soultaker schreef op 04 september 2004 @ 19:38:
Ik weet trouwens niet echt hoe je standard compliance moet meten. Ik denk dat er altijd nog wel ambiguïteiten in de standaard zullen zitten net zoals er altijd kleine fouten in C++ compilers zullen zitten. Wachten op de perfecte C++ compiler is als wachten op een foutloos besturingssysteem; daar kun je dus lang op wachten.

Van een foutloos OS heb je geen lijst van regels die je moet implementeren om dat te bereiken.

De C++ standaard is anders, daar staan gewoon een hele set regels in die geimplementeerd moeten worden om aan de standaard te voldoen. Dat is erg objectief. Je voldoet er aan of je voldoet er niet aan.

Bijna elke compiler heeft wel een aantal dingen die niet voldoen aan deze objectieve regels. Een hele simpele is bijvoorbeeld dat heel weinig compilers het export keyword implementeren. Comeau doet dat nu wel, maar het is echt een van de weinigen.

Natuurlijk zijn er wel een aantal defects en issues (TC1) en is er kleine tussen update (C++03), maar dat verklaart nog niet waarom zo lang duurt voordat C++98 helemaal geimplementeerd wordt.

[Soultaker]

flowerp schreef op 04 september 2004 @ 20:36:
Van een foutloos OS heb je geen lijst van regels die je moet implementeren om dat te bereiken.

Ik was al bang dat iemand dat zou zeggen, maar je kan bijvoorbeeld de Windows platform API zien als een 'volledige' specificatie van het besturingssysteem.

Een voldoende ingewikkelde specificatie is echter behoorlijk lastig te implementeren. In theorie kun je er best aan voldoen, maar in praktijk sluipen er kleine verschillen tussen specificatie en implementatie in de code. Je kunt die wel voorkomen of verhelpen, maar dat kost ontzettend veel moeite (zeker relatief aan het belang ervan). In zulke situaties heeft farlane gewoon een punt, zeker waar het commerciële compilers betreft.

Bijna elke compiler heeft wel een aantal dingen die niet voldoen aan deze objectieve regels. Een hele simpele is bijvoorbeeld dat heel weinig compilers het export keyword implementeren. Comeau doet dat nu wel, maar het is echt een van de weinigen.

Volgens mij is dat ook absoluut niet 'simpel' te implementeren.

[ReverendBizarre]

Je moet ook rekening houden met het feit dat er ook compiler bouwers zijn die er simpelweg niet aan willen voldoen omdat ze het niet volledig eens zijn met de gezette standaard. Neem Microsoft als voorbeeld. Ik kan me herrineren dat ik in de MSDN help ergens een pagina heb gezien waarin puntsgewijs uitgelegd wordt waar de Microsoft implementatie afwijkt van de standaard en daar stond expliciet bij dat dit kwam omdat MS het op deze punten niet eens is met de standaard.

Hoe dat met andere compiler bouwers zit weet ik niet maar het lijkt me niet ondenkbaar dat er meerdere zijn die op bepaalde punten gewoon niet mee willen gaan en dus gewoon nooit aan de standaard zullen voldoen.

Zolang de afwijkingen niet al te extreem zijn en ze goed gedocumenteerd zijn zie ik eerlijk gezegd ook het probleem niet zo.

[alienfruit]

Borland komt met een 100% standard-compliant C++ compiler, hiervan zit al een preview van bij, bij hun CbuilderX produkt.

[flowerp]

Soultaker schreef op 04 september 2004 @ 20:49:
In zulke situaties heeft farlane gewoon een punt, zeker waar het commerciële compilers betreft.

Dat is wel waar. Aan de andere kant zou dit dan nooit voor gcc gelden, maar die is ook niet 100%, in fact, gcc heeft nog niet eens de hoogste compliance. Mischien dat die laatste paar % wel gewoon door iedereen onzin gevonden worden en dat de standard comittee gewoon een onzinnige standaard (wat betreft die paar procentjes) heeft neergezet.

Hoe je farlane's woorden ook kunt interpreteren, is dat je geen nieuwe dingen moet toevoegen als het oude nog werkt. Tsja, als dat altijd zou worden aangehouden zaten we nu nog in assembler te coden.

Volgens mij is dat ook absoluut niet 'simpel' te implementeren.

Dat lijkt me ook niet, maar ik ben geen compiler bouwer. Zou export zo moeilijk zijn dat een team van programmeurs er 6 jaar lang 40 uur of langer per maand aan zou zitten te zwoegen? Waarschijnlijk niet. Mischien weegt de moeite die implementeren van export zou kosten gewoon niet op tegen de baten?

[farlane]

flowerp schreef op 05 september 2004 @ 00:27:
Hoe je farlane's woorden ook kunt interpreteren, is dat je geen nieuwe dingen moet toevoegen als het oude nog werkt.

Dat was niet de manier waarop ik het bedoelde. Ik denk dat die laatste paar procenten door relatief weinig mensen belangrijk gevonden wordt, omdat het vaak om dingen gaat die weinig gebruikt ( gaan ) worden.

Wees nou eerlijk; een export keyword zou handig zijn maar zijn templates nou echt onbruikbaar bij afwezigheid van die functionaliteit? Denk het niet. Volgens mij zijn dat echt dingen die niet bij de 'must have'' horen, maar bij de 'would be nice to have ( but i wont cry if it didnt )''

[Olaf van der Spek]

flowerp schreef op 04 september 2004 @ 19:22:
Zou je dus daar mischien uit kunnen concluderen dat een taal standaard wel in handen van een (groot) bedrijf moet zijn wil het niet 10 jaar duren voor een standaard in een concreet produkt omgezet wordt?

Kun je niet beter concluderen dat als een bedrijf zowel de compiler als de taal levert, het zeer waarschijnlijk is dat de twee 'redelijk' op elkaar aansluiten?

[Verwijderd]

Export heeft te maken met het OS. Als het OS niet netjes de C++ standaard volgt is het helaas einde verhaal. Zo heeft Windows maar een beperkte resolutie voor de naamgeving van geexporteerde functies. En dan is er ook nog overloading en name mangling wat tot dusver altijd gewrongen heeft. Ook Borland's CXpress compiler zal hier de standaard niet halen, gewoonweg omdat het OS de zaak niet trekt.

Niet dat het niet conform zijn mij problemen geeft. Tot dusver ligt het altijd aan mij als iets niet wil .

[Verwijderd]

OlafvdSpek schreef op 05 september 2004 @ 00:41:
[...]

Kun je niet beter concluderen dat als een bedrijf zowel de compiler als de taal levert, het zeer waarschijnlijk is dat de twee 'redelijk' op elkaar aansluiten?

Maar het ging juist niet om "redelijk". Het gaat hier om "perfect".

[Eelis]

.

[ Voor 113% gewijzigd door Eelis op 18-02-2015 19:12 ]

[MSalters]

Oei, dit gaat een lange post worden. Misschien vooraf even wat achtergrond: ik ben lid van WG21 ( de C++ commissie) en ken dus alle compiler vendors, en weet ook wat er speelt.

Op het moment is er nog maar een echt lastige feature, en dat is export. De andere features zitten in de debugging fase. Dan moet je denken aan problemen als het gebruikt van sizeof( ) in template argumenten en de gevolgen daarvan op name mangling - lastig maar op zich begrepen. Export daarentegen is fundamenteel lastig. Er komen daar een groot aantal issues bij elkaar: Je moet als het ware twee punten in je parsing saven (vanwege 2 phase name lookup) en die kunnen mergen. Dat is erg lastig als je interne parse representatie daar niet voor gebouwd is. Bovendien telt de exacte point of instantiation & point of declaration meer dan bij "normale" templates. Daar geld dat als A voor B komt, en B voor C, dan komt A voor C. Die vergelijking is niet meer houdbaar als B een exported template is.

Ondanks dat is het EDG gelukt. De kosten zijn naar schatting 1 tot 3 jaar werk geweest. Comeau heeft op basis hiervan zijn compiler gemaakt, en voor zover bekend is deze 100% compliant. Dat wil zeggen, EDG vertelt ons vaker dat de standaard subtiele bugs heeft dan andersom. Sommige eisen in de standaard spraken andere tegen - kijk maar naar de Defect Reports (en de namen daarop - de drie meest productieve DR schrijvers zijn geloof ik EDG)

Zou je dus daar mischien uit kunnen concluderen dat een taal standaard wel in handen van een (groot) bedrijf moet zijn wil het niet 10 jaar duren voor een standaard in een concreet produkt omgezet wordt?

Nee, dat is zaken omdraaien. In de gevallen die je noemt zet een bedrijf een product om in een standaard. Dat gaat makkelijker dan andersom.

mischien zo'n +- 2 jaar voor de opvolger van de huidige C++ standaard zal komen (die schat ik nu op zo rond 2010)

Ikzelf gok nog steeds op 2007-8 , ik heb al drafts lopen reviewen. Compiler vendors weten waar de pijn zit, en we hebben (nog) geen features met de complexiteit van export toegevoegd.

Ik kan me voorstellen dat het erg lastig om een compiler van voor 1998 zo aan te passen dat 'ie opeens standard compliant wordt. Je moet dan heel precies weten wat er allemaal veranderd is.

De code base van de huidige compilers is vaak 10-20 jaar oud. Er wordt permanent aan gesleuteld. De wijzigingen sinds 1998 zijn in vergelijking met 2 phase name lookup en export te verwaarlozen.

Ik vraag me ook af of het wel zinnig is om die laatste paar procenten aan conformiteit in je compiler te maken, als het zonder al sinds 1998 met veel success wordt gebruikt.

Er zijn mensen die daarom export in twijfel trekken, onder andere Andrei Alexandrescu recent in clc++m.

Mischien dat die laatste paar % wel gewoon door iedereen onzin gevonden worden en dat de standard comittee gewoon een onzinnige standaard (wat betreft die paar procentjes) heeft neergezet.

In dat soort gevallen stellen compiler vendors voor om zoiets te schrappen. Met export is dat gebeurd, Microsoft stelde voor om dat te schrappen. Dat is afgewezen; 80% vond dat export in C++ hoort.

Wees nou eerlijk; een export keyword zou handig zijn maar zijn templates nou echt onbruikbaar bij afwezigheid van die functionaliteit?

Export is voor library vendors. De bouwtijd van boost in grote projecten neemt hard toe; die templates worden keer op keer geparsed. Vergeet niet dat C++ ontworpen is om ook voor serieus grote (>10MLOC) projecten te werken. De eerste implementaties van export zijn nog geen snelheidswonderen, maar welke v1.0 is dat wel?

Export heeft te maken met het OS. Als het OS niet netjes de C++ standaard volgt is het helaas einde verhaal. Zo heeft Windows maar een beperkte resolutie voor de naamgeving van geexporteerde functies. En dan is er ook nog overloading en name mangling wat tot dusver altijd gewrongen heeft. Ook Borland's CXpress compiler zal hier de standaard niet halen, gewoonweg omdat het OS de zaak niet trekt.

Helaas, complete onzin. Niets van waar. Export heeft 0,niks met het OS te maken. Comeau levert op iets van 10 verschillende OS'en een export-capable compiler. Dat is ook logisch; export gebeurt tijdens de link-fase. De linker is een onderdeel van het C++ product, misschien niet wat we de compiler noemen maar wel deel van de implementatie.
Windows heeft bovendien geeneens een naamgeving voor C++, laat staan voor "geexporteerde functies" - export gaat over templates. Overloading is ook irrelevant, dat werkt met of zonder export hetzelfde. Name mangling is wel een punt, maar dat is weer geen OS issue. Het probleem voor Borland is kosten, niet het onderliggende OS.

[Soultaker]

Een vervolgvraag: wanneer wordt er nu eens een C++ ABI gestandaardiseerd?

Ik werk wel zo af en toe onder Windows en dan erger ik me er dood aan dat je van elke library een MSVC++6, MSVC++7, MinGW én Borland C++ Builder versie moet hebben (en dan hebben programmeurs met Digital Mars compilers enzo nog gewoon pech). Zeker omdat in de praktijk maar een paar compilers ondersteund worden en de jouwe er altijd net niet bij zit.

Onder UNIX speelt het probleem wat minder omdat libraries daar vaak vanuit source gecompiled worden en meestal wel met verschillende versies van GCC te compileren zijn, maar als dat niet lukt heb je daar dus precies hetzelfde probleem (want tenminste GCC 2.9, 3.0 en 3.3 zijn incompatible, als ik het me goed herinner).

Nu het al lang goed gelukt is om binaries te standaardiseren, zou dit een logische volgende stap moeten zijn. Ik vind het altijd gek dat ik onder FreeBSD probleemloos tegen Linux libraries kan linken maar dat ik niet kan linken tegen een library die met een nieuwere versie van GCC gecompileerd is.

[MSalters]

GCC heeft sinds 3.0 de nieuwe Itanium ABI, aangepast voor het lokale platform. Dat is dus een standaard.
Onder Windows is het probleem groter, maar niet onterecht. MSVC6 is oud, en absoluut niet conformant. Als je die 1997 ABI zou gebruiken veroordeel je VC7 daarmee ook tot non-confomance. Ik weet niet of Microsoft bezwaar maakt tegen het gebruik van deze C++ ABI door Borland. De C ABI mag wel gebruikt worden, dus ik denk dat het geen legal issue is.

Overigens moet met export alles weer op de schop. Export en compilers mixen is al helemaal een brok ellende - het compileren van een enkele class gebeurt dan door twee compilers (!)

[flowerp]

MSalters schreef op 05 september 2004 @ 12:46:
GCC heeft sinds 3.0 de nieuwe Itanium ABI, aangepast voor het lokale platform. Dat is dus een standaard.

Inderdaad, voor de itanium is de ABi wel gespecificeerd, als een van de weinige platforms. De 100 programmeurs wereldwijd die voor dat platform in C++ programmeren waren dan ook erg in hun nopjes ;-)

MSVC6 is oud, en absoluut niet conformant.

Laat Olaf v/d Spek dit maar niet horen. :-) ( ik dacht dat hij juist altijd als Vc6 advocate optreedt en claimed dat ie helemaal conformant is op een klein dingetje met templates na )

Overigens goede post over de huidige situatie van C++ compilers. Jou uitleg maakte het alweer een stuk duidelijker voor mij.

[Olaf van der Spek]

flowerp schreef op 05 september 2004 @ 16:14:
Laat Olaf v/d Spek dit maar niet horen. :-) ( ik dacht dat hij juist altijd als Vc6 advocate optreedt en claimed dat ie helemaal conformant is op een klein dingetje met templates na )

Hij mompelt ook gelijk wat over een mug en een olifant.

[MSalters]

Niks mis met VC6
_{zolang je het alleen als backend van Comeau gebruikt}

[flowerp]

MSalters schreef op 05 september 2004 @ 16:54:
Niks mis met VC6
_{zolang je het alleen als backend van Comeau gebruikt}

Voor de niet geinformeerden, je gebruikt dan alleen de C compiler modus van VC6. Comeau zet standard conformant C++ om in platform (OS, CPU, compiler) specificieke C code.

offtopic:
@Olaf
Het is natuurlijk een lolletje, maar ik kan me nog een post van jou herinneren waar je heel serieus vraagt op welk punt VC6 dan niet voldoet aan de C++ standaard. Volgens mij zijn er wel meer mensen op dit forum die je nog wel een plagen over die opmerking van toen. ;-) Net zoals als Bill Gates: 640k ought to be enough for everyone, oid.

[ Voor 35% gewijzigd door flowerp op 05-09-2004 19:34 ]

[Olaf van der Spek]

Verwijderd schreef op 05 september 2004 @ 00:44:
Maar het ging juist niet om "redelijk". Het gaat hier om "perfect".

Daarom stond redelijk ook tussen aanhalingstekens.
Het zou natuurlijk ook kunnen dat de specs volstaat met #ifdef IS_FEATURE_SUPPORTED
Feature, blah, blah, blah.
#endif.

offtopic:
Ik wilde inderdaad gewoon weten op welke punten VC6 niet voldeet aan de standaard ja.

[ Voor 18% gewijzigd door Olaf van der Spek op 05-09-2004 21:39 ]

[flowerp]

OlafvdSpek schreef op 05 september 2004 @ 21:34:
Ik wilde inderdaad gewoon weten op welke punten VC6 niet voldeet aan de standaard ja.

Voor als je het nog steeds niet weet, of voor andere mensen die zich dit afvragen; het staat gewoon in de MSDN documentatie. Ik denk niet in die versie die met Vc6 geshipped werd eind 97, want toen bestond de standaard nog niet eens, maar wel in latere editities.

Zo uit mijn hoofd implementeerde VC6 iets van 73% van de standaard, give or take a few percent. Wellicht dat andere mensen er anders over denken, maar ik denk dat het niet echt een goede zaak is als je anno 2004 nog een compiler uit 1997 gaat gebruiken. Voor opleidingen vind ik het echt -heel- slecht, je leert mensen dan al een verouderde implementatie aan. (overigens kun je de VC6 IDE natuurlijk wel lekkerder vinden, ik bedoel hier enkel de compiler cl.exe die bij VC6 hoort)

[Olaf van der Spek]

flowerp schreef op 05 september 2004 @ 23:53:
Voor opleidingen vind ik het echt -heel- slecht, je leert mensen dan al een verouderde implementatie aan.

Bepaalde opleidingen negeren zelfs STL volledig.

[.oisyn]

flowerp schreef op 04 september 2004 @ 20:36:
Een hele simpele is bijvoorbeeld dat heel weinig compilers het export keyword implementeren. Comeau doet dat nu wel, maar het is echt een van de weinigen.

Export is ook een beetje overrated. Het wordt vaak gezien als de heilige graal, maar in feite heb je er maar weinig aan. Want welk voordeel kun je er nou eigenlijk uit halen? Eigenlijk alleen dat je template implementaties in een library kunt stoppen, maar dat hoeft nog steeds niet te betekenen dat je niet bij de source kan. De "gecompileerde" vorm van exported templates moeten een 1:1 vertaling zijn van de code; het is dus altijd terug te halen, ik geloof zelfs dat je voor Comeau gewoon de letterlijke source van de templates nodig hebt bij het gebruik ervan. Ook wordt er gedacht dat de compileertijden omlaag gaan omdat je de implementatie niet meer hoeft te compilen. Niets is minder waar, ook voor exported templates geldt dat ze moeten werken in de context waarin ze gedefinieerd zijn. Omdat de header met de template declaratie overal vandaan geinclude kan worden kan de context dus ook per translation unit verschillen. En aangezien de implementatie van de template pas gecompileerd kan worden zodra die context duidelijk is, wordt er bij een export declaratie simpelweg een lookup gedaan naar die implementatie in een al dan niet voorgecompileerde vorm (als een voorgecompileerde vorm überhaupt mogelijk is, de parser heeft type-informatie nodig om de code ook maar te kunnen begrijpen). De implementatie moet dan alsnog gcompileerd worden, waardoor de uiteindelijke compileertijd niet eens afneemt (hij zou zelfs kunnen toenemen door die extra lookup stap)

Eelis schreef op 05 september 2004 @ 01:31:
[...]

Ik geloof hier helemaal niks van, heb je bronnen?

Wat ik er zo snel over kon vinden:
http://www.forum.nokia.com/main/0,6566,st_p_32,00.html

C++BuilderX notably eases platform portability by delivering a new Borland 100% ANSI/ISO C++ and C99 compliant compiler, as well as a C++ platform development framework to allow developers to visually build and deliver cross-platform applications that do not require compiler extensions. C++BuilderX offers extended support for mobile and embedded computing, continued integration with Borland C++ compilers as well as support for other widely used standards-based C++ compilers including, GCC, Intel, Metrowerks, Microsoft® Visual C++® and Sun® Forte C++.

[igmar]

flowerp schreef op 05 september 2004 @ 23:53:
Voor opleidingen vind ik het echt -heel- slecht, je leert mensen dan al een verouderde implementatie aan.

Waarbij ik me dan afvraag hoeveel programmeurs zowiezo de programmeertaal features ten volle gebruiken. Ik ken maar weinig programmeurs die geavanceerde C++ templates e.d. gebruiken, en het dan ook nog eens snappen.

[igmar]

OlafvdSpek schreef op 06 september 2004 @ 00:40:
Bepaalde opleidingen negeren zelfs STL volledig.

Omdat er teveel verschil in implementaties is. Dat verschil neemt af, maar je code gewoon naar een ander platform / compiler gooien is er gewoon vaak niet bij. Dat heeft tot gevolg dat men zich beperkt tot features die wel op alle compilers (grotendeels) werken, en dat heeft weer tot gevolg dat er minder vraag is naar de laatste CXX standaard.

[MSalters]

STL problemen? VC6 was de laatste gangbare compiler die problemen had, en die is End-Of-Life, unsupported, niet meer te koop, (insert Monty Pyhton parrot referenties).

[MSalters]

.oisyn schreef op 06 september 2004 @ 09:20:
Export is ook een beetje overrated. Het wordt vaak gezien als de heilige graal, maar in feite heb je er maar weinig aan. Want welk voordeel kun je er nou eigenlijk uit halen? Eigenlijk alleen dat je template implementaties in een library kunt stoppen, maar dat hoeft nog steeds niet te betekenen dat je niet bij de source kan. De "gecompileerde" vorm van exported templates moeten een 1:1 vertaling zijn van de code; het is dus altijd terug te halen, ik geloof zelfs dat je voor Comeau gewoon de letterlijke source van de templates nodig hebt bij het gebruik ervan. Ook wordt er gedacht dat de compileertijden omlaag gaan omdat je de implementatie niet meer hoeft te compilen. Niets is minder waar, ook voor exported templates geldt dat ze moeten werken in de context waarin ze gedefinieerd zijn. Omdat de header met de template declaratie overal vandaan geinclude kan worden kan de context dus ook per translation unit verschillen. En aangezien de implementatie van de template pas gecompileerd kan worden zodra die context duidelijk is, wordt er bij een export declaratie simpelweg een lookup gedaan naar die implementatie in een al dan niet voorgecompileerde vorm (als een voorgecompileerde vorm überhaupt mogelijk is, de parser heeft type-informatie nodig om de code ook maar te kunnen begrijpen). De implementatie moet dan alsnog gcompileerd worden, waardoor de uiteindelijke compileertijd niet eens afneemt (hij zou zelfs kunnen toenemen door die extra lookup stap)

FUD.

De gecompileerde versies hoeven absoluut geen 1 op 1 versie van de sources te zijn. Er is geen reden waarom ze langzamer moeten zijn, en EDG meldt al dat ze in hun recentere versies wel snelheidswinst bieden.
Dit komt onder andere omdat je tijdens de compilatie van de sources al een name-looku kunt doen van alle namen die onafhankelijk zijn van de template argumenten. Vaak gaat het dan om 90% van de namen. Het einge wat je moet opslaan is het deel van de parse boom die nog niet geresolved is. In GCC is dit al mogelijk, alleen het gericht importeren in de link fase werkt nog niet.
Omdat de overgebleven parse boom fors kleiner is, kan deze ook sneller worden gemerged met de instantiatie context.

[Verwijderd]

MSalters schreef op 06 september 2004 @ 13:13:
STL problemen? VC6 was de laatste gangbare compiler die problemen had, en die is End-Of-Life, unsupported, niet meer te koop, (insert Monty Pyhton parrot referenties).

offtopic:
Ik vind persoonlijk een Cthulhu referentie meer toepasselijk "the evil that lies dead but dreaming".

[igmar]

MSalters schreef op 06 september 2004 @ 13:13:
STL problemen? VC6 was de laatste gangbare compiler die problemen had, en die is End-Of-Life, unsupported, niet meer te koop, (insert Monty Pyhton parrot referenties).

Pak maar eens een wat minder gangbaar platform, en een OS specifieke compiler. Windows is niet het enige platform op deze wereld.

[MSalters]

Noem er eens een? STLport of GCC zijn op dat soort platformen de norm. GCC heeft ook een behoorlijke STL. GreenHills is misschien de enige achterblijver, maar ook die komen aardig bij (omdat je moeilijk geld kunt vragen voor een brakke library als GCC gratis is)

[.oisyn]

MSalters schreef op 06 september 2004 @ 13:23:
[...]

FUD.

De gecompileerde versies hoeven absoluut geen 1 op 1 versie van de sources te zijn. Er is geen reden waarom ze langzamer moeten zijn, en EDG meldt al dat ze in hun recentere versies wel snelheidswinst bieden.
Dit komt onder andere omdat je tijdens de compilatie van de sources al een name-looku kunt doen van alle namen die onafhankelijk zijn van de template argumenten. Vaak gaat het dan om 90% van de namen. Het einge wat je moet opslaan is het deel van de parse boom die nog niet geresolved is. In GCC is dit al mogelijk, alleen het gericht importeren in de link fase werkt nog niet.
Omdat de overgebleven parse boom fors kleiner is, kan deze ook sneller worden gemerged met de instantiatie context.

Ok, misschien was langzamer een beetje overdreven, maar het punt is dat je pas code generation en optimalisation kunt doen nadat de template werkelijk geinstantieerd is, of je nou export gebruikt of niet. En dat terwijl er van export vaak wordt gedacht dat de template implementatie al "gecompileerd" wordt, net als normale library code, wat natuurlijk niet het geval is.

Ik zit iig niet te wachten op exports, zoveel voordeel is er niet (implementatie scheiden van declaratie kun je ook wel zonder export )

Hoe werkt name lookup trouwens precies met exported templates? Want je zit met 3 verschillende contexts; de implementatie (datgene wat in de library gaat), de declaratie (de header die je include) en de uiteindelijke instantiatie. Hoe worden die afgezocht op zoek naar names en overloads?

[ Voor 5% gewijzigd door .oisyn op 06-09-2004 19:30 ]

[MSalters]

Implementatie fysiek scheiden (dus ook name contexts) lukt echt niet zonder export. Trust me, ik heb het geprobeerd.

Name lookup met export gebeurt als volgt: tijdens het compileren heb je eerst de fase waarin de source van het template wordt gecompileerd. De source wordt dan in tokens opgebroken en van elk token wordt bepaald waar het voor staat. Dat is dus de reden waarom je in templates soms de "typename" of "template" prefix voor een identifier moet zetten, omdat de compiler anders niet weet wat een dependent MyClass::x voor iets is. Vervolgens worden de non-dependent namen (die dus niet van template parameters afhangen) opgezcoht in de lokale scope. De scope die hierbij wordt gebruikt is de scope waar het token daadwerkelijk voorkomt, dus een gewone call naar foo() wordt gewoon ter plekke geresolved alsof de call in een non-template functie staat.

Namen die wel dependent zijn worden nog niet lokaal opgezocht omdat je nog geen gebruik kunt maken van Argument Dependent Lookup. Daarvoor heb je de desbetreffende namespace namelijk nodig, en die weet je nog niet van een template parameter T.

Vervolgens wordt het template geinstantieerd met een class MyNS::MyClass. Op dit moment wordt er eenl ookup gedaan voor de namen die dependent zijn op MyClass. Hierbij wordt een normale lookup gedaan in de template source (logisch, daar wordt MyClass::x genoemd)
en een argument-dependent lookup in de scope op de point van instantiatie (logisch, alleen daar kun je de goede headers voor MyNS includen). De namen die je dan vindt worden samegemikt, en de beste wordt verder via een vrij normale procedure bepaald.

Subtiliteiten: als de template parameter een base class is, dan worden daardoor de base class members niet meer direct zichtbaar. Een call foo() wordt niet opgevat als een call this->foo(). 'this' is namelijk dan wel dependent, maar een unqualified name als foo() is dat niet. Die wordt dus in de eerste fase gevonden, of niet.

De name lookup heeft in in principe niets met de scope in de header te maken, en dat is precies het doel: zorgen dat je headers simpel, schoon en niet-intrusief zijn.

[igmar]

MSalters schreef op 06 september 2004 @ 14:10:
Noem er eens een? STLport of GCC zijn op dat soort platformen de norm.

Hetgeen niet altijd beschikbaar is, en ook niet altijd bruikbaar. Om maar eens wat voorbeelden te noemen : SCO UnixWare, SunOS 5.x, Solaris 7.xx

GCC heeft ook een behoorlijke STL. GreenHills is misschien de enige achterblijver, maar ook die komen aardig bij (omdat je moeilijk geld kunt vragen voor een brakke library als GCC gratis is)

GCC 3.x heeft een goede STL, alles wat ouder is iig niet. Met GCC zijn de problemen relatief gering, en is d'r info beschikbaar wat er nog niet werk, en dat zijn dingen die ik iig niet gebruik.

[RetepV]

Het tijdschrift Dr.Dobbs houdt elk jaar een test m.b.t. de compatibiliteit met de C++ standaard van compilers. De laatste keer dat ik die zag (ik denk in 2003) bleek heel verassend dat Microsoft's Visual C++ 7.0 heel dicht tegen de standaard aan zat.

De Visual C++ 7.0 compiler is degene die je bij Visual Studio .NET krijgt.

Ik vond dat echt verassend omdat Microsoft doorgaans juist tegen standaarden in gaat om zich te kunnen onderscheiden van de concurrentie. Ze hoeven namelijk niet aan standaarden te voldoen, ze kunnen hun eigen 'standaarden' namelijk zonder tegensputteren naarbinnen kruien en de developers hebben het dan maar slikken.

Edit:

Ik heb het even opgezocht. Het gaat om Dr.Dobbs Journal, November 2003, pagina 54. Ik heb enigszins geluld, het was de Intel 7.1 compiler, niet de VC++ 7.1 compiler.

Lijstje:

code:

edg 3.2            99.70%
Comeau 4.3.2       99.55%
Intel 7.1          99.55%
PGCC 4.1-2         99.11%
VC++ 7.1           98.22%
gcc 3.3            96.14%
Borland 6.0        92.73%
Watcom 1.0         78.49%

De VC++ 6.0 compiler was maar 83.43% compatible met de standaard. Van 83.43% naar 98.22% vind ik een hele prestatie.

[ Voor 33% gewijzigd door RetepV op 07-09-2004 18:24 ]

[.oisyn]

RetepV schreef op 07 september 2004 @ 18:16:
De VC++ 6.0 compiler was maar 83.43% compatible met de standaard. Van 83.43% naar 98.22% vind ik een hele prestatie.

Er zat nog een stap tussen hoor, namelijk vs.net 2002 (de 7.0 versie dus). Ik denk dat die er zo ongeveer tussen in lag

[Verwijderd]

.oisyn schreef op 07 september 2004 @ 18:59:

Er zat nog een stap tussen hoor, namelijk vs.net 2002 (de 7.0 versie dus). Ik denk dat die er zo ongeveer tussen in lag

7.0 was kwa C++ standaard maar een kleine verbetering. 7.1 was de grote vooruitgang, er kwam toen ook de verklaring dat C++ conformance belangrijk was.