zurück zum Artikel

Hinter dem neuen Standard steht ein Prozess, an dem internationale Experten engagiert teilnehmen. Ein Werkstatteinblick in das oft zähe Handwerk der Normierung.

Die Programmiersprache C++ und ihre wichtigsten Bibliotheken sind seit 1998 ein Standard der Internationalen Organisation für Normung (International Organization for Standardization, kurz: ISO). Seit der Veröffentlichung des ersten Standards C++98 hat es mehrere Aktualisierungen gegeben. Der neueste Standard, C++20, ist zwar noch nicht offiziell verabschiedet, mehrere Features sind jedoch bereits in verschiedenen Compilern verfügbar.

"C mit Klassen": Anfänge des C++-Standards

Erste Arbeiten an C++ datieren in das Jahr 1979 zurück, damals noch unter dem Arbeitstitel "C mit Klassen". Ziel war es zunächst, die Effizienz von C mit der Produktivität objektorientierter Sprachen wie Simula zu verbinden. Später kamen weitere Programmierparadigmen wie generische und Metaprogrammierung hinzu, und C++ entwickelte sich zu einer recht komplexen Multiparadigmensprache. 1998 erschien der erste Standard der Sprache und 2003 eine Nachbesserung davon. Der folgende Standard war ursprünglich für die Nullerjahre geplant und trug daher den Arbeitstitel "C++0x". Da C++ dafür radikal überarbeitet, um nicht zu sagen, neu erfunden wurde, hat sich dieser Prozess bis 2011 hingezogen. Spötter haben C++11 daher auch hexadezimal als "C++0xb" bezeichnet. Seither hat die ISO regelmäßig alle drei Jahre einen neuen Standard verabschiedet (C++14, C++17, C++20 – s. Abb. 1).

Selbst Corona wird diesen Rhythmus wahrscheinlich nicht unterbrechen. Der Vorsitzende des ISO-Standardkomitees Herb Sutter hatte als Reaktion auf die Verzögerungen bei C++11 eine strenge Taktung vorgeschlagen, die sich auch als Zugmodell veranschaulichen lässt: "Wer rechtzeitig da ist, fährt mit; wer nicht, muss auf den nächsten Zug [i. S. v. Standard] warten" (Quelle: Bjarne Stroustrup, Thriving in a Crowded and Changing World, S. 21 [1] [1]). Mehr dazu lässt sich dem Kasten "Planmäßige Abfahrt" [2] entnehmen.

C++ und die Neuordnung der Dinge

"Nichts ist schwieriger auszuführen, unsicherer hinsichtlich des Erfolgs und gefährlicher zu handhaben als das Schaffen einer neuen Ordnung. Denn der Reformer zieht sich die Feindschaft derer zu, die von dem alten System profitiert hatten, und findet nur laue Verteidiger unter den Nutznießern des Neuen."

- Niccolò Machiavelli, Der Fürst (1513), als Motto für Standardisierung zitiert in der Printversion dieses Artikels. Er ist Teil des Developer-Sonderhefts "Modernes C++" [3], in dem er sich auf den Seiten 84 bis 90 befindet.

Internationaler Standardisierungsprozess

Die International Organization for Standardization mit Sitz in Genf ist die Vereinigung nationaler Normungsorganisationen. Ihr Gründungsjahr war 1947, die offiziellen Amts- und Arbeitssprachen sind bis heute britisches Englisch, Französisch und Russisch. Derzeit sind 165 Länder Mitgliedsstaaten bei der ISO. Im Subkomitee für Programmiersprachen sind etwa 21 Länder als stimmberechtigte Mitglieder vertreten [4], wobei die genaue Zahl Schwankungen unterliegt (s. Abb. 2). Weitere Länder nehmen als Beobachter an den Standardisierungsprozessen teil, auch Organisationen wie Ecma International und die Linux Foundation haben Vertreter bei der ISO (mehr Informationen finden sich im Kasten "Subkomitee für Programmiersprachen").

Um beim Übersetzen des Organisationsnamens nicht unterschiedliche Akronyme in verschiedenen Sprachen zu haben, hat man sich auf die gemeinsame Kurzform ISO – vom griechischen "isos" für "gleich" – verständigt. In der Zusammenarbeit mit den nationalen Komitees arbeiten von der ISO anerkannte Experten Entwürfe aus, und die ISO schlägt sie den entsprechenden Expertengremien der nationalen Komitees vor. In vielen Fällen spiegeln die Strukturen der nationalen Organisationen die der ISO wider. [5]

Phasen auf dem Weg

Die Entwicklung eines internationalen Standards erfolgt in mehreren Phasen. In der anfänglichen Antragsphase wird eine Projektbeschreibung – New Work Item Proposal (NP) – verfasst und den nationalen Gremien vorgeschlagen. Stimmen mindestens fünf Nationen dem Projekt zu, beginnt die offizielle Arbeit am Standard. In der folgenden Komiteephase werden Committee Drafts (CDs) erarbeitet, die eine Zustimmungsrate von mindestens zwei Dritteln der zur Abstimmung berechtigten nationalen Komitees erfordern. Nicht alle nationalen Komitees sind bei den Programmiersprachen aktiv, und die Programmiersprachen haben auch unterschiedlich stark besetzte Ausschüsse. Daher nehmen deutlich weniger Nationen an der Abstimmung teil, als insgesamt in der ISO vertreten sind. In der Vergangenheit stimmten bei den Standardisierungen von C++ etwa zehn bis zwölf Nationen ab [7], künftig werden es womöglich mehr.

Daneben können und sollen die nationalen Komitees (unabhängig von ihrem Status als stimmberechtigtes oder beobachtendes Mitglied) Kommentare zu erwünschten und erforderlichen Änderungen einbringen. Die Experten der ISO müssen auf diese Kommentare reagieren und versuchen, den Standard entsprechend nachzubessern. In Einzelfällen kommt es auch vor, dass die ISO-Experten die im nationalen Kommentar vorgeschlagene Änderung nach einer Prüfung zurückweisen, da sie zu der Erkenntnis gelangt sind, dass der Status quo besser oder die Änderung noch nicht ausgereift ist. In einem größeren Projekt – wie bei der Standardisierung von C++ – können auch mehrere aufeinanderfolgende CDs verfasst werden.

Draft for International Standard (DIS)

In der Überprüfungsphase wird ein Draft for International Standard (DIS) erstellt, der neben den zwei Dritteln an Zustimmung der stimmberechtigten Teilnehmer der jeweiligen Abstimmung auch erfordert, dass nicht mehr als ein Viertel der nationalen Komitees dagegen stimmt. Wenn es im Idealfall keine Gegenstimmen gibt, kann das Dokument die letzte Phase überspringen und wird direkt als internationaler Standard veröffentlicht. In dieser Phase befand sich C++20, während die Printversion dieses Artikels entstand: Die Mitglieder des Ausschusses für Programmiersprachen hatten bis zum 14. August 2020 Zeit, im Namen des Deutschen Instituts für Normung (DIN) über den C++20-Draft (DIS) mit der offiziellen Dokumentenbezeichnung N2638 abzustimmen.

Soweit sie an der Abstimmung teilgenommen haben, haben alle Stimmberechtigten für den Standard gestimmt, ohne weitere Kommentare abzugeben. Der Entwurf (DIS) von C++20 wurde am 4. September 2020 einstimmig angenommen und hat damit dem Vorsitzenden der zuständigen WG21-Arbeitsgruppe Herb Sutter zufolge die endgültige technische Genehmigung erhalten. Die finale redaktionelle Überarbeitung und formelle Veröffentlichung erfolgte Ende 2020.

Hätte der DIS auf diesem Weg nicht genügend Zustimmung erfahren, wäre der Prozess in die Bestätigungsphase gegangen, in der die stimmberechtigten Mitglieder das Standarddokument als Final Draft for International Standard (FDIS) nicht mehr kommentieren, sondern nur noch bestätigen oder ablehnen dürfen. Die Kriterien sind die gleichen wie beim DIS: Mindestens eine Zweidrittelmehrheit an Zustimmungen und höchstens ein Viertel an Ablehnungen (nicht mehr als derzeit fünf Gegenstimmen) führen zur Annahme des vorgeschlagenen Standards.

Technische Spezifikationen (TS)

Neben diesem Vorgehen für Internationale Standards (IS) können die ISO-Gremien auch technische Spezifikationen (TS) erarbeiten. Das wird in C++ häufig bei umfangreicheren Features – wie den Concepts oder dem Dateisystem – gemacht, wenn unsicher ist, ob die Spezifikation des Features bei der Verabschiedung des nächsten Sprachstandards den hohen Ansprüchen des Komitees wohl gerecht werden kann. Dann wären neben der Hauptspezifikation des Features auch alle Verweise darauf in letzter Minute aus dem C++-Standard zu entfernen. Mithilfe einer TS kann eine Arbeitsgruppe an einem neuen Feature deutlich unabhängiger arbeiten. Sobald das Komitee davon überzeugt ist, dass die Spezifikation des Features in der TS so weit ausgereift ist, dass es die Fertigstellung des nächsten C++-Standards nicht gefährdet, wird die TS an den entsprechenden Stellen im Entwurf des internationalen Standards eingefügt.

Ein konkretes Beispiel wäre das schon vor einiger Zeit vorgestellte Feature "Design by Contract", zu dem drei Vorschläge und vier Gegenvorschläge eingingen. Es fand noch keine abschließende Zustimmung, da noch nicht alle Experten es für ausgereift hielten. Nun wartet der C++20-Zug nicht auf die Fertigstellung des Features, sondern rollt gemäß Fahrplan aus, und das Feature muss auf den nächsten Standard warten. Um das Genfer Ticket für C++23 zu erhalten, muss es erst alle Phasen des Standardisierungsprozesses durchlaufen haben.

Reisebeschränkungen und Disruption durch die Pandemie

Vor dem Corona-Ausbruch im Frühjahr 2020 traf sich das Standardkomitee regelmäßig. Diese Treffen fanden früher zweimal jährlich und vor der Verabschiedung eines neuen Standards auch dreimal im Jahr statt. Seit 2016 gab es aufgrund der massiv gestiegenen Aktivität jährlich sogar drei Sitzungen. Da das US-amerikanische Komitee ANSI (American National Standards Institute) mit Abstand die meisten Experten stellt, sind die ISO-Sitzungen aus praktischen Gründen zugleich auch Sitzungen des entsprechenden ANSI-Komitees. Daher fanden die Sitzungen traditionellerweise auch mindestens einmal pro Jahr in den USA und mindestens einmal in einem anderen Land statt.

Aufgrund der im März von der Regierung Trump eingeführten Reisebeschränkungen waren die letzten drei Sitzungen in Europa verortet (Köln, Belfast, Prag), und eine geplante vierte (in der bulgarischen Hafenstadt Varna) wurde nur wegen der Pandemie verschoben. Bei den letzten Sitzungen war typischerweise etwa ein Dutzend Nationen vertreten, darunter Experten aus Bulgarien, Deutschland, Finnland, Frankreich, Großbritannien, Kanada, den Niederlanden, Polen, Russland, Spanien, der Schweiz, der Tschechischen Republik und den USA. Dies mag im Verhältnis zu den insgesamt 165 Mitgliedsstaaten als wenig erscheinen, stellt aber schon eine Verbesserung zur Vergangenheit dar, als sich nur sieben bis acht Nationen aktiv an der C++-Standardisierung beteiligt hatten [8] und osteuropäische Länder noch nicht vertreten waren.

Normaler Ablauf der Sitzungen

Die Sitzungen dauern immer von Montagmorgen bis Samstag gegen Mittag. Während der Eröffnung werden kurz die relevanten Richtlinien umrissen, alle stimmberechtigten Teilnehmer verabschieden das Protokoll der vorigen Sitzung und einzelne Teilnehmer berichten über Aktivitäten des Komitees und anderer relevanter Organisationen. Daraufhin werden die Diskussionsrunden der Arbeitsgruppen im Komitee organisiert. Diese Diskussionsrunden erstrecken sich dann bis Freitag. Die Arbeitsgruppenleiter reichen abschließend ihre sogenannten Motions ein, das sind formale Anträge auf Änderungen am Standard. Für solche Änderungen muss es in der Arbeitsgruppe einen deutlichen Konsens geben. Dafür sind mindestens zwei Drittel an Jastimmen erforderlich, angestrebt ist sogar eine Zustimmungsrate von drei Vierteln.

Am Samstag findet unter Leitung des Vorsitzenden die offizielle Abstimmung mit dem gesamten Komitee statt. Früher war das ein zweistufiges Verfahren: Erst erfolgte die Abstimmung der US-amerikanischen Delegation und danach eine Abstimmung nach Ländern. Herb Sutter als der derzeitige Vorsitzende hat dieses Vorgehen vor einigen Jahren dahin gehend geändert, dass zunächst eine Abstimmung unabhängig von der Staatszugehörigkeit stattfindet (wobei in der US-Delegation nur eine Stimme pro Institution und nicht pro Experte zulässig ist). Das Ziel dieser Abstimmung ist es, zu ermitteln, ob der vom Komitee erarbeitete Standardentwurf gute Chancen auf Akzeptanz durch die nationalen Komitees hat.

Falls der Vorsitzende feststellt, dass die Gegenstimmen von Vertretern mehrerer Nationen kommen, findet noch eine in Länder untergliederte Abstimmung statt. Letzteres ist jedoch selten der Fall und kam 2019 in Köln nicht vor. Auch hier ist ein deutlicher Konsens erforderlich, das heißt zwei Drittel an Jastimmen sowohl unter den Experten als auch unter den Nationen. Um das mühsame Auszählen der Stimmen zu vermeiden, fragt der Vorsitzende zunächst nach Einwänden gegen eine einstimmige Zustimmung und klärt damit, ob eine Abstimmung überhaupt erforderlich ist.

Das C++-Komitee wächst und wächst

Das Standardisierungskomitee für C++ ist innerhalb der ISO offiziell die Arbeitsgruppe ISO/IEC JTC1/SC22/WG21, wobei JTC1 für "Joint Technical Committee 1", SC22 für "Subcommittee 22" (zuständig für Programmiersprachen) und WG21 für "Working Group 21" steht. Um als Experte mitzuarbeiten, muss man sich durch die jeweilige nationale Normungsinstitution – in Deutschland das DIN (Deutsches Institut für Normung) – delegieren lassen.

Wie Abbildung 3 illustriert, ist das C++-Komitee seit 1990 deutlich gewachsen. Bei den letzten Sitzungen waren regelmäßig über 100 Experten anwesend. Erfreulicherweise ist auch die deutsche Präsenz darin immer stärker geworden. Zeitweise gab es keine deutsche Delegation, und der Verfasser war bei seiner ersten Sitzung 2008 der einzige offizielle Vertreter des Deutschen Instituts für Normung (DIN). Die anwesenden deutschen Experten waren keine DIN-Mitglieder, und umgekehrt waren die meisten DIN-Mitglieder damals Akademiker, die mangels passender Reisebudgets nicht an den Sitzungen teilnehmen konnten. In den letzten Jahren waren immer mehrere offizielle DIN-Vertreter bei den Meetings vor Ort.

Das ISO-Komitee lässt auch Gäste bei den Sitzungen zu. Eigentlich sollte man sich vor der zweiten Teilnahme von seiner nationalen Institution legitimieren lassen, aber diese Regelung wird nicht streng kontrolliert. Die offiziellen Vertreter sind einander jedoch persönlich so weit bekannt, dass die Teilnahme nicht registrierter Gäste an den Abstimmungen auffallen würde. Gerade die Sitzung vergangenes Jahr in Köln hat zahlreiche deutsche Nichtmitglieder zusätzlich angezogen. Viele C++-Freunde haben die Gelegenheit beim Schopf ergriffen, die Standardisierung einmal aus der Nähe zu verfolgen, sodass neben dem guten Dutzend offizieller deutscher Vertreter noch etwa doppelt bis dreimal so viele Gäste anwesend waren.

Hierarchischere Strukturen und neue Study Groups

Das Komitee ist nicht nur zahlenmäßig gewachsen, die Struktur der internen Arbeitsgruppen ist – wie in Abbildung 4 dargestellt – auch zunehmend hierarchischer geworden. 2008 gab es lediglich drei Arbeitsgruppen: Core, Evolution und Library. In der Arbeitsgruppe "Evolution" wurden neue Sprachfeatures diskutiert und ihre endgültige Spezifikation in der Gruppe "Core" ausformuliert. Die Library-Arbeitsgruppe hat alle Themen im Zusammenhang mit der Standardbibliothek bearbeitet. Diese Arbeitsgruppe wurde dann in "Library" und "Library Evolution" aufgespalten, wobei sich letztere mit den Neuerungen in der Standardbibliothek beschäftigt.

Im Laufe der Zeit sind daneben noch eine Reihe von Study Groups entstanden, die sich auf je ein umfangreicheres Element wie Concepts oder Module spezialisiert haben (s. Abb. 3). Wenn ein Feature im Großen und Ganzen ausgearbeitet ist und Aufnahme in den Standard gefunden hat, kann solch eine Study Group auch wieder stillgelegt werden. Eventuell aufkommende Detailprobleme bearbeitet dann eine andere Arbeitsgruppe wie Core. Neben den vier großen Arbeitsgruppen Core, Evolution, Library und Library Evolution gibt es zurzeit folgende aktive Study Groups mit zumeist offensichtlichen Themen:

• Concurrency: Parallelität und Nebenläufigkeit
• Modules
• Networking
• Transactional Memory
• Numerics: unter anderem Festkomma-, dezimale Gleitkommazahlen, rationale Zahlen
• Feature Test: portable Tests, ob ein Compiler ein bestimmtes Feature unterstützt
• Compile-Time Programming
• Undefined Behavior and Vulnerabilities: kohärente Verbesserungen gegen undefiniertes oder unspezifiziertes Verhalten und Schwachstellen
• Human-Machine Interface und I/O: Ausgabegeräte wie Grafik und Audio, Eingabegeräte
• Game Development and Low Latency
• Tooling: Entwicklerwerkzeuge (insbesondere bezüglich Modulen) und Paketierung; Evolution Working Group Incubator: Vorabdiskussionen für die Evolution Working Group
• Library Evolution Working Group Incubator: wie die vorangegangene für Library Evolution
• Machine Learning: KI-spezifische Funktionen, aber auch lineare Algebra und Graphalgorithmen
• Education: Empfehlungen zum Lehren von modernem C++
• Contracts: Sprachunterstützung für Design by Contract.

Vier Study Groups ruhen zurzeit: File System, Concepts, Ranges und Data Bases. Bei einer Sitzung des Komitees tagen immer mehrere Gruppen gleichzeitig. Während 2008 noch drei Besprechungen parallel liefen, gab es im Juni 2019 in Köln durchschnittlich sieben bis acht parallele Diskussionsrunden. Dabei fanden sich die vier Hauptarbeitsgruppen über den gesamten Sitzungszeitraum hinweg zusammen. Auch die beiden Incubator-Gruppen haben fast über den gesamten Zeitraum hinweg getagt (es gibt immer viel Neues in C++). Manche Study Groups wie Compile-Time Programming haben sich nur einen halben Tag lang getroffen. Gruppen mit weniger Input tagen auch nicht bei jeder Sitzung.

Lebenszyklus eines Standardisierungsvorschlags

Um ein neues Feature in den Standard aufzunehmen, muss jemand einen Vorschlag dafür einreichen, und bis zur endgültigen Standardisierung durchläuft dessen Bearbeitung mehrere Phasen. Mit der zuvor beschriebenen feingranularen Strukturierung des Komitees spielen die Arbeits- und Studiengruppen verschiedene Rollen und werden in unterschiedlichen Phasen des Standardisierungsprozesses aktiv. Diese Rollen sind:

• Akzeptanz: Die beiden Incubator Study Groups entscheiden, ob es sich lohnt, eine neue Idee weiterzuverfolgen.
• Domänenexpertise: Die anderen Study Groups diskutieren, inwieweit der Vorschlag dem Wissensstand des jeweiligen Fachgebiets gerecht wird.
• Design: Die beiden Arbeitsgruppen Evolution und Library Evolution verfeinern die Umsetzung der Idee. Das umfasst technische Details – etwa welche Funktionsargumente konstant sein sollten oder ob etwas zur Compilezeit berechenbar sein soll und ob die Schnittstelle einen Konflikt mit anderen Features birgt.
• Formulierung: Die beiden anderen Arbeitsgruppen Core und Library – im Weiteren Wortgruppen genannt – diskutieren die genaue Formulierung, die es in den Standard aufzunehmen gilt.

Durch diese Aufgabenteilung durchläuft ein Vorschlag für ein neues Sprachfeature typischerweise die folgenden Phasen:

1. Coole Idee, die in einem Blog, einer Mailingliste, Reddit et cetera veröffentlicht wird. (Die meisten Vorschläge schaffen es nie über dieses Stadium hinaus.)
2. Die Antragsteller reichen ein erstes Designkonzept ein und stellen es meist als Erstes der Incubator-Gruppe vor. Der Entwurf sollte eine Begründung, in Betracht gezogene Alternativen, konkrete Beispiele und einen konkreten Vorschlag enthalten, der detailliert genug ist, um ihn zu bewerten.
3. Die Incubator-Gruppe bekundet Interesse und veranlasst, dass die Diskussion dieses allgemeinen Features in die nächste Runde geht. Daraufhin leitet sie den Vorschlag an die Designgruppe und (soweit vorhanden) parallel an eine Gruppe von Domainexperten weiter.
4. Die Design- und Expertengruppen bitten nach ausführlichen Diskussionen um Nachbesserungen. Das wiederholt sich in der Regel über mehrere Sitzungen. Liegen konkurrierende Vorschläge vor, dauert die Iteration und Konvergenz etwas länger. Wenn viele Iterationen erforderlich sind und zwischen den Sitzungen zusätzliche persönliche oder telefonischen Sitzungen infrage kommen, kann der Vorsitzende der Designgruppe empfehlen, eine Studiengruppe für das Thema zu gründen. Überarbeitete Vorschläge wandern dann wieder in die Entwurfsgruppe zurück.
5. Die Designgruppe stimmt zu, eine bestimmte ausgereifte Designrichtung zu verfolgen, und bittet um eine erste Ausformulierung für den Standardtext.
6. Die Designgruppe stimmt zu, eine bestimmte ausgereifte Designrichtung zu verfolgen, und bittet um eine erste Ausformulierung für den Standardtext.
7. Die Wortgruppe überprüft und verfeinert die Formulierung, bevor sie letztlich zustimmt, die Featurespezifikation in den aktuellen Entwurf des Sprachstandards aufzunehmen. Daraufhin erhält das gesamte Komitee den Vorschlag zur Abstimmung.
8. Das gesamte Komitee stimmt zu, den Wortlaut in den aktuellen C++-Entwurf zu übernehmen, und erstellt eine Issue-Liste zum Nachverfolgen von Problemfragen.
9. Design- und Wortgruppen verfeinern die Spezifikation und leiten jede Änderung zur Genehmigung an das komplette Komitee weiter. Der Wortlaut muss das verabschiedete Design korrekt beschreiben; alle Fragen dazu, was bestimmte Codebeispiele bedeuten sollen, müssen im Design gelöst werden und sich in der Formulierung widerspiegeln; der Wortlaut muss so klar sein, dass die Compilerentwickler exakt wissen, was sie zu implementieren haben. Das Ziel ist, dass alle Programmierer portablen Code schreiben können, der bei verschiedenen Compilerimplementierungen auf die gleiche Weise funktioniert.
10. Das vollständige Komitee sendet den Arbeitsentwurf (CD oder DIS) zur Abstimmung über ISO an die nationalen Standardinstitutionen, und einige Monate später senden diese die Kommentare zur Abstimmung an das Komitee zurück.
11. Design- und Wortgruppen entscheiden über Kommentare zur Abstimmung und leiten jede Änderung zur Genehmigung an das gesamte Komitee weiter.
12. Das vollständige Komitee sendet den Arbeitsentwurf (FDIS) zur endgültigen Abstimmung und/oder Veröffentlichung.
13. Wurde der Vorschlag zunächst in einem TS veröffentlicht, kann das Komitee nach Erhalt von Beta-Feedback (normalerweise einschließlich der Erfahrung eines Compileranbieters, der das Feature implementiert und dies von Nutzern hat testen lassen) den Editor beauftragen, den TS in den Arbeitsentwurf von C++ zu integrieren.

Ein kleiner und wenig kontroverser Vorschlag kann mehrere Phasen während eines Meetings durchlaufen, während andere Vorschläge mehrere Meetings für eine einzelne Phase benötigen.

Fazit

Die Standardisierung von C++ ist keine einfache Sache. Welcher Aufwand jedoch wirklich dahinter steckt, das kann man wohl erst erahnen, wenn man selbst daran teilgenommen oder gar versucht hat, eine Änderung im Standard durchzuboxen. Das ISO-Standardisierungskomitee ist zwar eine staatliche Institution, allerdings kommt es in der Praxis des Standardisierens auf hohes privates Engagement an. Umso mehr ist der ehrenamtliche Einsatz aller Beteiligten zu würdigen. Mit C++20 hat sich die Sprache noch einmal deutlich weiterentwickelt und bietet uns Programmierern eine ganze Reihe wunderbarer Verbesserungen.

Dr. Peter Gottschling
ist Gründer und Geschäftsführer der Firma SimuNova [9], die die Matrix Template Library weiterentwickelt sowie Training und Beratung zu C++ anbietet. Sein Buch "Discovering Modern C++" soll bald in der zweiten, auf C++20 aktualisierten Auflage erscheinen. Er ist Mitglied des ISO-Komitees zur Standardisierung von C++, Obmann des Programmiersprachenausschusses des DIN und Gründer der C++-User Group Dresden.

Literatur:

[1] Bjarne Stroustrup; Thriving in a Crowded and Changing World: C++ 2006–2020 (2020); in: Proceedings of the Fourth ACM SIGPLAN Conference on History of Programming Languages; Association for Computing Machinery: doi.org/10.1145/3386320, S. 21

[2] zitiert nach Bjarne Stroustrup; The C++ Programming Language; Addison-Wesley 1985 (4. Aufl. 2013), S. 448 (dt. Einführung in die Programmierung mit C++)

(sih [10])

URL dieses Artikels:
https://www.heise.de/-5994676

Links in diesem Artikel:
[1] https://dl.acm.org/doi/10.1145/3386320
[2] #anchor_1
[3] https://shop.heise.de/ix-developer-modernes-c/PDF
[4] https://www.iso.org/who-develops-standards.html
[5] 
[6] https://dl.acm.org/doi/10.1145/3386320
[7] https://www.iso.org/sites/ConsumersStandards/voting_iso.html
[8] https://www.iso.org/members.html
[9] https://www.simunova.com/de/
[10] mailto:sih@ix.de

Copyright © 2021 Heise Medien