Ausblick auf den C++14-Standard

Sprachen  –  2 Kommentare

Die neue Version des C++-Standards ist so gut wie fertig. Groß sollen die Änderungen nicht sein, dafür aber schneller festgeschrieben werden. Eine Auswahl dessen, was jetzt schon steht und was die aktuellen Compiler bereits unterstützen.

Was schenkt man jemandem, der eigentlich schon alles hat? Eine neue Uhr, ein Handtäschchen oder ein neues Handy? Dinge eben, die das Leben ein wenig schöner und einfacher machen, aber ohne die man im Grunde auch sehr gut auskommen könnte. Nach dem durchaus substanziellen und notwendigen Update von C++03 auf C++11 könnte man bei den Änderungen des C++14-Standards denselben Eindruck bekommen.

Die mit der Standardisierung betreuten Parteien haben sich im Fall von C++14 für ein äußerst behutsames Vorgehen beim Umbau der Sprache entschieden. Umwälzungen, die bei den Nutzern ein komplettes Umdenken erforderten, wird es kaum geben. Und so ist auch für den Standard zu erwarten, dass die meisten C++-Programmierer so weitermachen könnten wie bisher. Nur: Sie müssen es nicht.

Das C++-Standardkomitee hat sich nach der Verabschiedung von C++11 auf einen deutlich schnelleren Release-Zyklus geeinigt und, was noch wichtiger ist, diesen Wunsch auch in die Tat umgesetzt. Herb Sutter – der aktuelle Vorsitzende des C++-Standardkomitees – schrieb schon im Februar 2014 in seinem "Trip Report" zum "Winter ISO C++ meeting": "C++14: We’re done! (we think)". Und er ließ Mitte August folgen: "We have C++14!" Wer sich tiefer in das Thema ein arbeiten möchte, für den mag das nun ein guter Zeitpunkt sein, den frei verfügbaren C++14-Draft-Standard herunterzuladen. Das finale Dokument dürfte, wie zuvor schon bei C++11, nur gegen Zahlung eines Entgelts erhältlich sein.

Der kürzere Release-Zyklus hat den Preis, dass Änderungen deutlich kleiner ausfallen. Herb Sutter zitiert in seinem Vortrag "The Future of C++" Bjarne Stroustrup, den Erfinder der Sprache, so, dass C++14 eher eine Art C++11.1 würde, also ein inkrementelles Update auf C++11. Das nächste große Release ist erst für 2017 vorgesehen und wird entsprechend als C++17 bezeichnet.

Compiler müssen noch nachziehen

Gleichzeitig mangelt es selbst für C++11 manchen Compilern noch an vollständiger Unterstützung, und bis dieser Sprachstandard – geschweige denn C++14 – samt aller Neuerungen die dominante Plattform für Produktionscode in den konservativeren Industriezweigen darstellt, können noch Jahre vergehen. Insofern schadet das vorsichtige Vorgehen des Standard- Komitees sicherlich nicht – sonst liefe man eventuell Gefahr, dass die Nutzer den Anschluss verlieren. Und ohne sie nützt der schönste Standard nichts.

Einen Überblick über die Abdeckung von C++14- (und C++11-) Features aktueller Compiler liefert zum Beispiel der "C++11/14 compiler and library shootout". Demnach (und laut den zugehörigen Webseiten) ist die Unterstützung für C++11 bei den "freien" Compilern GCC ab Version 4.8 und Clang ab Version 3.3 wohl am weitesten gediehen – sie decken ihn vollständig ab. Komplette Unterstützung des C++14-Standard bietet zurzeit allein Clang 3.4. Allerdings ist der Autor auf einer Testmaschine mit Ubuntu 13.10 auch bei diesem Compiler auf Probleme gestoßen.

Nebenbei bemerkt arbeitet man am CERN an einer Ergänzung zu Clang unter dem Namen "Cling", einem C++-Interpreter. Er soll den in der dortigen Analysesoftware ROOT eingesetzten C++-Interpreter "CINT" ersetzen. Die Einsatzmöglichkeiten eines C++-Interpreters auf Basis eines C++14- fähigen Compiler-Frameworks dürften über die Teilchenphysik weit hinausgehen (man denke nur an IDEs oder die Code-Analyse), sodass aus der Cling/Clang-Ecke sicherlich noch viel zu hören sein wird.

Aus den kleinen bis mittelgroßen Änderungen von C++14 greift dieser Artikel einige heraus. Wer will, findet im C++14-Kapitel des Status-Dokuments zu Clang die Links zu den Papers, die alle neuen Eigenschaften einzeln und im Detail beschreiben. Der Versuch, sich dies alles über das C++14-(Draft-)Standard-Dokument anzueignen, dürfte angesichts des Umfangs von über 1300 Seiten hingegen zum Scheitern verurteilt sein. Dieses ist wohl eher als Nachschlagewerk nützlich, wenn man ein Feature bereits kennt und Details darüber wissen möchte.

In der Praxis hilfreich dürfte beispielsweise die Möglichkeit sein, den Rückgabetyp von Lambda-Ausdrücken automatisch bestimmen zu lassen. Für einfache Ausdrücke mit nur einem return-Statement war dies zwar schon in C++11 machbar. In C++14 aber lassen sich jetzt beliebig viele return-Statements (gleichen Rückgabetyps) mit komplexen Kontrollstrukturen verbinden. Dies dürfte helfen, die etwas sperrige Lambda-Syntax von C++11 in Bezug auf die Rückgabetypen zu entschärfen.