C++11 – auch ein Stimmungsbild
Auch wenn C++ nicht gerade als beliebt unter Entwicklern gelten darf: die Sprache wird sie noch eine Weile begleiten – vor allem, weil der Bedarf an hardwarenahen Sprachen wie C++ sich noch erhöhen dürfte. Jetzt ist die Sprache in einer neuen Version erschienen.
- Marc Mutz
Auch wenn C++ nicht gerade als beliebt unter Entwicklern gelten darf: die Sprache wird sie noch eine Weile begleiten – vor allem, weil der Bedarf an hardwarenahen Sprachen wie C++ sich noch erhöhen dürfte. Jetzt ist die Sprache in einer neuen Version erschienen.
Die Sprachen C und C++ gelten als komplex, ja geradezu gefährlich. Eine informelle Meinungsumfrage unter Kollegen des Autors (alles Leute, die täglich mit C++ arbeiten) zeigt dann auch, dass sie keineswegs nur geliebt werden. Die Kommentare reichen von: "Manchmal mag ich ihre Schönheit und Einfachheit. Aber dann schäme ich mich (und erinnere mich all der Stunden, die ich mit Fehlersuche zugebracht habe)" bis zu: "Ich würde C++ hassen, wenn es Qt nicht gäbe". Ein weiterer Kollege liefert gleich eine Aufzählung an Punkten, als hätte er seinen Ärger über die Zeit angespart: C++ sei übermäßig komplex, man brauche Jahre, um es zu meistern. Klobig sei es, nicht agil und nicht modern. Und normalerweise unsicher. Die Stimmung ist demnach relativ negativ.
Nach Meinung des Autors sind die Sprachen der (direkten) C-Familie (C/C++ und D) immer noch die einzigen, die sich für die Systemprogrammierung eignen. Nur sie bringen die Voraussetzungen (zum Beispiel Hardwarenähe) mit, Rechner bis an ihre Leistungsgrenze auszureizen. Ulrich Drepper sprach das in einem Vortrag auf einem früheren LinuxTag am Beispiel von NUMA-Architekturen (Non-Uniform Memory Access) an: Im Gegensatz zu Fortran, C und C++, so der GLIBC-Maintainer, seien die zur Ausreizung der Möglichkeiten moderner NUMA-Systeme nötigen Programmierschnittstellen zur Speicher- und Prozessaffinität in anderen Sprachen noch nicht einmal vorhanden.
Herb Sutter schlug in dieselbe Kerbe, als er auf der diesjährigen "C++ And Beyond"-Konferenz in seiner Keynote "Why C++" das Ende des verlorenen Jahrzehnts für C++ und die Rückbesinnung auf Performance, und damit auf C++, auch und vor allem bei seinem Arbeitgeber Microsoft, herausstellte.
Auch wenn die Aussagen und die damit einhergehenden Implikationen mit einer Portion Skepsis zu behandeln sind, zeigen sie beispielhaft eine weitverbreitete Ansicht: C und C++ sind Sprachen für die Systemprogrammierung, Java, C# und Konsorten sind nur für die Anwendungsentwicklung geeignet. Vertreter beider Lager stellen zwar gerne heraus, dass ihre Sprache sehr wohl in der Domäne der anderen zu überzeugen vermag, doch ist ein Anwendungsentwicklerteam gut beraten, C++ nur zu wählen, wenn das notwendig ist, um die Hardware auszureizen. Und umgekehrt.
Gerade deshalb haben jedoch C++ und die "sauberere C++-Alternative" D gute Chancen, verloren gegangenes Terrain (zurück) zu erobern. Die aktuelle Diskrepanz zwischen dem Fortschritt in der Parallelität der Hardware auf der einen Seite und der vergleichsweisen Rückständigkeit der Programmiermodelle auf Softwareseite zwingen (System- und Anwendungs-)Entwickler im Moment dazu, sich mit der Hardware auf einer Ebene zu beschäftigen, wie das seit den 1980er-Jahren nicht mehr der Fall war.
Damals zählte man Taktzyklen von Assembler-Befehlen, heute zählt man Bytes in Cachelines, um False Sharing zu verhindern, oder der Entwickler hantiert mit (etwa SSE) Intrinsics (Streaming SIMD Extensions) herum, weil die Compiler immer noch nicht selbst optimalen SIMD-Code erzeugen können. Beides sind Gebiete, in denen (nur) C/C++ und D punkten können; anderen Sprachen fehlt die Nähe zur Hardware. Insofern ist jetzt eine aufregende Zeit – insbesondere für C++. Auf der einen Seite wird mit C und C++ schon seit Dekaden Multithreading praktiziert, auch wenn erst das jetzt veröffentlichte C++11 ein dafür geeignetes Speichermodell enthält. Aus der Vielzahl neuer Techniken seien nur OpenMP, Cilk++, RapidMind, Threading Building Blocks (TBB), CUDA, OpenCL und Ct genannt. Außer OpenCL sind diese Tools nur mit C/C++ kompatibel. Der scheinbar ewige Vorsprung von Java und C# bei den Trendwerkzeugen scheint zumindest in einem Teilbereich zum ersten Mal seit etwas mehr als zehn Jahren gebrochen.
Auf der anderen Seite ergeben sich durch die Template-Metaprogrammierung in C++ und D Mittel, numerischen Code auf einer Ebene zu (be)schreiben, für die in anderen Sprachen die Sprache selbst zu erweitern wäre, und dem Compiler durch geeignete Metaprogrammierung den effizienten Umgang mit Vektorerweiterungen in den heutigen Prozessoren beizubringen. Die Programmierschnittstellen, so sich jemand daran setzte, sie zu realisieren (dem Autor ist kein solches Projekt bekannt), hätten eine ganz andere Qualität und Stärke des Ausdrucks als die heute gängigen Bibliotheken, in denen nur solche Operationen beschleunigt möglich sind, für die die Bibliothek (zumeist) händisch optimierte explizite Routinen bereitstellt. Dass es prinzipiell viel generischer geht, hat Todd Veldhuizen mit Blitz++ vor 16 Jahren erfolgreich demonstriert (ohne allerdings Autoparallelisierung anzustreben).
Da es dem neuen C++-Standard gelingt, die Sprache wesentlich anwenderfreundlicher zu gestalten, kann der Einsatz von C++ wieder merklich zunehmen. Viele der neuen Sprachfunktionen in C++11 sind direkt der Sprach-Usability gewidmet (aus der Vielzahl sei nur auto genannt oder die Erlaubnis, vector<pair<U,V>> anstelle von vector<pair<U,V> > zu schreiben). Auch bind(), Lambdas und shared_ptr/unique_ptr ersetzen faktisch besonders benutzerunfreundliche Komponenten der 98er-STL (bind1st/bind2nd beziehungsweise auto_ptr).
In dieser Aufzählung sollten sich ursprünglich auch Konzepte befinden, auch eingeschränkte Templates (engl.: constrained templates) genannt. Die Mitglieder des Standardisierungskomittees entschieden sich jedoch 2009, nach einem Artikel Bjarne Stroustrups, seines Zeichens Erfinder von C++, Konzepte wieder aus dem Standard zu entfernen und erst in der nächsten Version der Sprache die Arbeit daran wieder aufzunehmen.
Nach den negativen Erfahrungen mit früheren Entscheidungen, die ihren Weg ohne die notwendige Erfahrung aus der Praxis in den Standard gefunden haben, darunter "externe" Templates, auto_ptr und Ausnahme-Spezifikationen (void foo() throw()), scheint es rückblickend eine weise Entscheidung gewesen zu sein, auf Konzepte vorerst zu verzichten. Hier hat man aus den Fehlern der Vergangenheit gelernt.
In einem weiteren Artikel spricht Stroustrup davon, Konzepte in C++1y, den nächsten C++-Standard, aufzunehmen. Interessant (und nach Meinung des Autors notwendig angesichts der Schnelllebigkeit der IT-Industrie), ist der Zeitrahmen: Nach nur fünf statt wie zuletzt zwölf Jahren soll C++1y seinen Vorgänger beerben.
In der Zwischenzeit wird sich das Komittee voraussichtlich dem seit 2005 liegen gebliebenen Technical Report 2 (TR2) widmen, der C++11 mit neuen Standardbibliotheken bereichern soll, so wie es TR1 für C++98 erfolgreich vorgeführt hat. Bisher hat es die Boost.FileSystem-Bibliothek in den TR2 geschafft. Auch Boost.Asio (async I/O), eine Netzwerk-Bibliothek, steht bereits in den Startlöchern. Der Autor erwartet außerdem eine Fülle von Bibliotheken die sich dem Thema Multithreading widmen, so zum Beispiel eine Threadpool- oder generische Task-Bibliothek. Damit schlösse sich der Kreis wieder, denn eine der ersten Bibliotheken, die Stroustrup in seiner Sprache entwickelt hat, war eine ebensolche Task-Bibliothek.
