Der C++-Standardisierungs-Prozess
-
Der C++-Standardisierungs-Prozess
Für viele ist C++ eine unbekannte Sprache, was die Organisation angeht. In diesem Artikel soll etwas Licht ins Dunkel gebracht werden.
1 Weltweite Normen
C++ ist eine der wenigen Programmiersprachen die in einem internationalen Standard (also einer Norm) festgelegt sind. Was heißt das genau? Es gibt von der ISO (International Standard Organisation) ein "Papier" in dem genau drin steht, wie die Sprache C++ auszusehen hat. Dabei wird jedes Detail, wie Syntax, Eigenschaften und Verhalten, beschrieben. Unter anderem auch undefiniertes Verhalten. Auch die zu C++ gehörende Bibliothek (C++ Standard Library) ist ausführlich beschrieben. Dies ergibt einen offiziellen Standard an den sich jeder Hersteller eines C++ Compilers und dessen Bibliothek halten sollte (Normen sind nicht bindend!). Man kann das mit der DIN (Deutsches Institut für Normung) für z.B. Papier vergleichen. Jeder von uns hat schon mal standardisiertes Papier gekauft, z.B. DIN-A4-Papier. Die DIN schreibt die Abmessungen (Breite mal Länge) für Papier bis auf den Millimeter genau vor. So kann man beim Papierkauf nicht sehr viel falsch machen. Und auch in 100 Jahren werden wir wahrscheinlich DIN-A4-Schreibblöcke kaufen können.
Die DIN ist eine nationale Organisation für deutsche Normen, entsprechend ist z.B. die ANSI (American National Standards Institute) die nationale Organisation für die USA. Für weltweit gültige Normen gibt es jedoch die ISO, welche aus den nationalen Normungs-Organisationen besteht. Genau hier wurde 1998 die C++-Sprache als Standard verabschiedet und die nationalen Organisationen haben den ISO-C++-Standard bei sich übernommen. C++ finden wir also nicht nur im ANSI sondern auch im DIN. Wir können somit auch bedenkenlos DIN-C++ sagen.
2 Das Komitee
Damit C++ überhaupt ein ISO-Standard werden konnte, mussten diverse Bedingungen erfüllt werden, die nicht nur für C++ gültig sind. Die ISO schreibt unter anderem vor, dass am Standardisierungsprozess nicht nur eine einzige rechtliche Person und auch nicht mehrere nur aus einem Land mitwirken dürfen. D.h. es müssen sich mehrere Personen aus mehreren Ländern auf einen Standard einigen. Denn immerhin handelt es sich ja um einen internationalen Standard. Vorzugsweise sind diese Personen von Firmen entsendet, um am Prozess Einfluss zu haben (denn die Akzeptanz für den Standard muss später bei den Firmen vorhanden sein). Zum Beispiel waren und sind immer noch am Standardisierungsprozess für C++ Firmenvertreter von Microsoft, IBM, Intel, HP, Dinkumware u.a. beteiligt. Teilweise sind auch Mitglieder z.B. von der DIN aus Berlin mit dabei. Alle Personen bilden das C++-Komitee um über den C++-Standard zu entscheiden.
Doch wie arbeitet das C++-Komitee? Da die Mitglieder des Komitees aus aller Welt kommen, ist deren Handlung nicht ganz so flexibel, wie z.B. die einer lokalen Gruppe. Der wohl größte Teil des Komitees, wenn nicht sogar alle, sind zwar Angestellte namhafter Firmen, doch arbeiten diese letztendlich ehrenamtlich im C++-Komitee. D.h. die Arbeit über das Jahr und die Jahre geht meistens auf das Freizeitkonto. Die Kommunikation läuft dabei über eine geschlossene Mailingliste ab, in der sich die Mitglieder auf dem aktuellen Stand halten und diskutieren. Damit jedoch die Arbeit nicht im Sande verläuft, finden im April und Oktober eines jeden Jahres persönliche Treffen statt. Der Ort ist dabei immer in einem anderen Land, z.B. fand das Treffen im April 2006 in Berlin statt. Im kommenden Oktober 2006 findet es in Oregon, USA, statt. Die Zahl der Teilnehmer bewegt sich dabei in einer Größenordnung von ca. 50 Personen, weshalb diese Treffen meistens in Hotels mit entsprechenden Räumlichkeiten stattfinden. Da die Arbeit, wie bereits gesagt, ehrenamtlich ist, müssen Treffen dieser Art von jemandem gesponsert werden. In Berlin ist für die anfallenden Kosten die DIN e.V. aufgekommen. In Oregon werden Intel und die ANSI die Kosten übernehmen. Für die Hotelzimmer müssen selbstverständlich die jeweiligen Personen selbst aufkommen.
3 Proposals
Was passiert nun auf diesen persönlichen Treffen? Das dürfte wohl das interessanteste sein. Solch ein Treffen dauert meistens ca. eine Arbeitswoche in der sowohl der aktuelle Stand verkündet wird, als auch sich Arbeitsgruppen zurückziehen und neue Vorschläge (Proposals) ausarbeiten oder eher besprechen. Mit Vorschlägen sind tatsächlich neue Spracheigenschaften, Toolspezifikationen oder Bibliothekserweiterungen gemeint. Doch wo kommen diese her? Hier kommt auch der Leser dieses Artikels ins Spiel. Jeder interessierte Mensch, der eine Idee für den C++-Standard hat, darf beim C++-Komitee einen Vorschlag einreichen. Das Komitee bittet sogar darum, das sich die C++-Community mit Vorschlägen beteiligt. 2005 wurden vor allem Vorschlagswünsche offiziell vom Komitee geäußert, was bisher eigentlich nicht vorkam.
Wer einen Vorschlag einreicht, muss diesen auf einem Treffen persönlich vortragen und für Antworten des Komitees zur Verfügung stehen. Sollte ein persönliches Erscheinen nicht möglich sein, kann man versuchen ein Mitglied frühzeitig mit dem Vorschlag vertraut zu machen. Dieses Mitglied kann dann die Vertretung übernehmen. Natürlich ist es aber besser, wenn der Initiator des Vorschlags selbst präsent ist.
Da der Prozess für einen neuen Standard sehr langwierig ist, sind vor allem neue Bibliotheksvorschläge vom Komitee gerne gesehen. Neue Bibliotheken können nämlich in einen Technical Report (TR) eingebracht werden, der verhältnismäßig schnell verabschiedet werden kann. Im April 2006 wurde z.B. endlich der TR1 verabschiedet.
Wie muss solch ein Vorschlag aussehen? Auf der Homepage des Komitees kann man viele bereits eingereichte Vorschläge vorfinden, auch eine kurze Beschreibung wie so etwas aussehen soll, ist vorhanden. Ein Vorschlag z.B. für eine XML-Bibliothek kann nur ein Konzept oder das Interface der Klassen beschreiben. Eine Implementierung muss nicht vorgewiesen werden. Hier erwartet das Komitee also keine Komplettlösungen. Denn meistens implementieren Compiler-Hersteller diese sowieso selbst oder kaufen sie ein. Es ist aber natürlich nicht von der Hand zu weisen, das eine Referenzimplementierung oder gar der Einsatz in kommerziellen produktiven Systemen ein gutes Argument für die Akzeptierung des Vorschlages sein kann. Es muss noch betont werden, dass nicht nur Bibliotheksvorschläge eingereicht werden können. Es kann zu jedem Thema bzgl. des C++ Standards von jedem ein Vorschlag eingereicht werden.
4 Das Stimmrecht
Die Akzeptierung eines Vorschlags läuft über das Komitee ab in dem jedes Mitglied für oder dagegen stimmen kann. Wer hat alles ein Stimmrecht? Im Prinzip jeder, der Mitglied ist. Und eine Mitgliedschaft kann man sich erkaufen. Wer in Deutschland lebt, kann z.B. über eine DIN-Mitgliedschaft versuchen ein Stimmrecht zu erhalten. Ein paar DIN-Mitglieder können hier sicherlich mehr Auskunft geben und sind in den Protokollen der Komitee-Homepage auffindbar.
Meistens wird nicht direkt nach einem Vortrag des Vorschlags abgestimmt, sondern in einem späteren Meeting, wenn sich die Mitglieder über die Mailingliste genauer ausgetauscht haben. Auch werden manchmal vom Komitee Kritikpunkte genannt die der Einreicher zu einem späteren Termin nachbessern kann und eine neue Chance bekommt. Es kommt aber auch vor, dass Vorschläge komplett abgelehnt werden, weil sie den Vorstellungen des Komitees in keiner Weise entsprechen.
Im TR1 wurden z.B. spezielle mathematische Funktionen bei der Abstimmung aus reinen Kostengründen abgelehnt. Hier haben Compiler- und Library-Hersteller ihre Bedenken bzgl. des Aufwandes für Implementierung und vor allem der QS (Qualitätssicherung) geäußert. Denn ein Dilemma à la export-Schlüsselwort aus dem 1998er Standard, will man nicht wieder erleben.
5 Verabschiedung
Wie man sehr schön sieht, ist der Standardisierungsprozess für C++ mit viel Aufwand verbunden. Bis ein Standard verabschiedet wird, gehen viele Jahre ins Land. Das hatte bereits der erste C++-Standard gezeigt und der nächste kommt hoffentlich in diesem Jahrzehnt. Um hier etwas schneller voranzukommen, wurden die TRs eingeführt, die in vielen anderen ISO-Standards schon gängig sind.
Letztendlich muss sich das gesamte Komitee für den nächsten Standard in allen Punkten bzw. Vorschlägen einig sein. Am Ende wird dann ein Entwurf zusammengefasst, der als offizielles ISO-Dokument erscheint.
6 Die Zukunft
Was bringt die Zukunft? Der nächste C++-Standard hat den Arbeitstitel C++0x und soll verdeutlichen, das dieser noch in diesem Jahrzehnt verabschiedet wird. Einige Komiteemitglieder scherzen jedoch, dass der Platzhalter ein Hexadezimalwert sei. Es könnte also auch C++0A werden. Es ist jedoch 2009 mit dem nächsten C++-Standard zu rechnen. Denn nur noch bis Frühjahr 2007 werden Proposals für C++0x angenommen und für den TR2 ist schon im Oktober 2006 Einsendeschluss.
Da Technical Reports nur Erweiterungen zum Standard sind, wird der TR1 vermutlich (teilweise) mit in den C++0x-Standard einfließen. Hier hat das Komitee noch keine Entscheidung getroffen. Da der TR1 aber "nur" auf C++ von 1998 bzw. 2003 aufbaut und deshalb keinen C++0x-Compiler benötigt, wird dieser mittlerweile schon von diversen Organisationen implementiert. Sowohl Dinkumware, GCC als auch Boost arbeiten an Implementierungen. STLport wird sicherlich nachziehen. Dinkumware wird wahrscheinlich seinen Großkunden Microsoft und Borland auch eine Implementierung anbieten. Somit werden wohl alle bekannteren C++-Compiler demnächst mit TR1 ausgeliefert oder sich damit leicht erweitern lassen.
Zum Abschluss noch ein paar wichtige URLs:
C++-Komitee-Homepage: http://www.open-std.org/jtc1/sc22/wg21/
C++-TR1-Entwurf: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf
C++-TR2-Wünsche: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html
Die ISO: http://www.iso.org
Die DIN: http://www.din.de
-
Sehr schöner Artikel
Habe einiges an interessantem Hintergrundwissen
dazugelernt.Noch einige Fragen:
-Könnte man export nicht auch wieder abschaffen?
Export wird ja sowieso von fast keinem Compiler unterstützt
-Müssen die beschlossenen Standard Abwärtskompatibel sein?
-Stimmt es das boost als eine Art Entwicklungszweig gebraucht wird?
-
Danke!
-Könnte man export nicht auch wieder abschaffen?
Darüber wurde im Komitee diskutiert da es praktisch kaum eine Chance gibt, das es weitere Compiler geben wird, die export unterstützen werden. (aus reinen Kostengründen!) Das Ergebnis lautet, das export drin bleiben wird. Der Grund ist, das wenn einmal ein Feature rausgenommen wird, es nicht unwahrscheinlich ist, das morgen jemand kommt und ein anderes Feature gerne streichen lassen will. Also sagt man, das alles so bleibt wie es ist und in Zukunft besser vorher über sowas nachgedacht wird (was beim TR1 mit den speziellen Math-Funktionen auch passiert ist).
-Müssen die beschlossenen Standard Abwärtskompatibel sein?
Hem, eigentlich kommt ja ein neuer Standard raus. Da wird dann sicherlich alles vom 2003er wieder mit drin stehen. Ist also eher eine Entscheidung des Komitees und kein Muss.
-Stimmt es das boost als eine Art Entwicklungszweig gebraucht wird?
Wie meinst du das mit "gebraucht wird"? Boost wurde von ein paar Komiteemitgliedern ins Leben gerufen. Ist somit auf jeden Fall eine gute Anlaufstelle, wenn man seine eigene Lib irgendwann im Standard sehen will.
Als einzelkämpfer ist sowas schwieriger.Adobe macht das jetzt mit ihrer GIL, bisher konnte man diese auf http://opensource.adobe.com/gil runter laden. Vor ca. zwei Wochen wurde in der Boost-Mailingliste ein Antrag für die Aufnahme in Boost bzw. für ein Review beantragt, weil Adobe sein GIL irgendwann im Standard einbringen will. Und über Boost ist es sicherlich einfacher. Aber auch keine Garantie.
-
Da Mitte Oktober das Komitee-Meeting in Portland war, wurde heute endlich das Protokoll des Meetings veröffentlicht:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2110.htmlWer alle Dokumente des Portland-Meetings sichten will, findet hier eine Auflistung zum Stöbern:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/#mailing2006-11
-
-
Sehr interessant, danke!
-
Schöner Artikel und trotz trockener Materie angenehm zu lesen.
-
Sehr interesanter Artikel
, aber was hat es mit
> Denn ein Dilemma à la export-Schlüsselwort aus dem 1998er Standard, will man nicht wieder erleben.
auf sich?Und was hat es mit dem Witz (den ich auch nicht kapiere) "Wer den unterschied zwischen C++98 und C++03 kennt, leist einfach zu viele Dokuemte" auf sich?
Gruss Jan
-
Das export Schlüsselwort ist nahezu unmöglich zu implementieren.
Bzw. der Aufwand steht in keinem Verhältnis zum nutzten.
Deshalb gibt es eigentlich auch keine standardkonformen Compiler für C++.
-
Richtig, Storm.Xapek.de hats schon gesagt. Kann noch hinzufügen, das die TR1 auch als eine Art Probelauf des nächsten Standard anzusehen sind. Durch die TR1-Nutzung kann man Praxiserfahrung sammeln und notfalls im C++0x noch korrigieren. Auch werden Dinge wie Template-Concepts bereits im GCC ausprobiert. Alles Erfahrungen die man aus export und C++98 gelernt hat.
-
Möchte diesen Thread mal aus aktuellem Anlass ausbuddeln:
Ab nächstes Jahr ist das für Deutschland alles graue Theorie, weil die DIN das Gremium für ISO Programmiersprachen einstellt.
Damit gibt es auch keine deutsche Delegation für die Standardisierung von C++ mehr...Und ich weiss dass von einer sehr gut informierten Quelle, und habe es leider auch von der DIN so bestätigt bekommen.
Diskussionsthread dazu: http://www.c-plusplus.net/forum/p2268580#2268580