Mit C++ bin ich 1991 in Kontakt gekommen, damals im Rahmen einer Seminargruppe an der Humboldt-Universität. Das Thema hiess offiziell "Entwurf objektorienter Klassenbibliotheken in C++" und untersuchte die Eignung der noch sehr jungen Sprache für die damals ebenfalls recht junge Objektorientierung, die man bis dahin vor allem als Smalltalk kannte.

Von einer Standard-Template-Library (STL) war man damals weit entfernt, tatsächlich existierte das Schlüsselwort "template" noch gar nicht (es war allerdings schon reserviert). Hauptsächlich untersuchten wir damals die Standard-Streams von C++ (damals noch ohne Mehrfachvererbung), die Smalltalk-ähnliche NIH-Klassenbibliothek (aka NIHCL) und die LEDA-Bibliothek mit einem reichen Fundus algorithmischer Klassen.

Das C++ Programmiermodell stieß damals noch an seine Grenzen, die ersten breitenwirksamen Anwendungen fanden sich vor allem in Widget-Bibliotheken (MFC, WxWindows), bei denen man die vieldiskutierten Möglichkeiten der Polymorphie benutzen konnte um das Erstellen neuer Fenster-Elemente zu vereinfachen. Die anderen ähnlichen Ansätze der frühen 1990er Jahre sind inzwischen ausgestorben (z.B. VTK, WGT) oder Nischenprodukte (FLTK).

Der nächste große Schub kam nach meinem Gefühl durch die Qt-Bibliothek von Trolltech, die ich in schon in der ersten öffentlichen Vorabversion kennenlernte. Es räumte mit dem Missbrauch der Polymorphie auf, und erlaubte erstmal die dynamische Kreation von Fensterelemente über Zustandsautomaten. Leider konnte ich meinen damaligen Arbeitgeber Tektronix nicht von dem Konzept überzeugen, denen eine Version 0.9 nicht schmeckte, und sie setzten für die neuentwickelten Geräte auf MFC.

In der ersten Version von Qt setzte man auch noch keine Template-Klassen ein, da die Definition zwar existierte, die meisten C++ Compiler jedoch noch ernste Probleme damit hatten. Stattdessen setzte man auf eigene Container-Klassen statt der STL-Basisklassen, die mittels Makros gebaut wurden. Erst mit Fortentwicklung der STL und dessen steigender Popularität im praktischen Einsatz wechselte man - zuerst wurden die eigenen Basisklassen auf Template-Klassen umgestellt, später auch die STL-Basisklassen direkt unterstützt.

Letztlich bin ich immer ein Fan von Einfachvererbung geblieben, wie ich sie noch aus den ersten Tagen von C++ kenne, ich mag statische Template-Klassen, lehne Template-Funktionen ab und wünsche mir immer noch, dass man (wieder) die Laufzeit-Erstellung von Klassen erlaubt, wie sie formal in COM und Smalltalk existiert, wo es Metaobjekte gibt, die die Funktionalität von Klassenobjekten übernehmen. Aber man kann halt nicht alles haben - manches wurde in den späteren objektorientierten Sprache wie Java/C# behoben.

Sollte man C++ heute noch einsetzen? Oh ja, aber man sollte beherzigen, dass das "alte" C++ eine Reihe moderner Konzepte nicht kennt oder spät eingeführt hat (z.B. namespaces und lokale Klassen/Funktionen). Dafür erhält man die Möglichkeit, über "inline" und statische Templates einen enormen Geschwindigkeitsvorteil gegenüber dynamischer Objekteorientierung zu erhalten, trotzdem der Code stark auf der Wiederverwendung von Bibliotheksalgorithmen basiert. Diese kann ein moderner C++ Compiler erstaunlich gut einer Zieloptiemierung unterwerfen. - Wo es aber keinen zeitkritischen Code gibt, ist eine Managed-Objects Umgebung sinnvoller (Java, C#, Python).

Projekte

Die Zahl der neu erstellten Projekte hält sich in Grenzen, da ich durch die Aneignung objektorientierter Prinzipien schon lange problemlos Bibliotheken in blankem C schreiben kann, die dennoch eine objektorientierte Verwendung finden. Man schreibt dann um den Code einfach C++ Interfaces herum - gleichzeitig gewinnt man aber die Möglichkeit, die Funktionen in anderen Programmiersysteme einzubinden, seien es Skriptsprachen oder Java (JNI), die für die Nutzer-zentrierte Programmierung geeignet sind. Gerade unter C# ist der Import von C Symbolen besonders einfach geraten.

So ist C++ vor allem dort anzutreffen, wo es eng an eine Oberfläche gebunden ist. Bei Tektronix etwa gibt es einen grafischen Editor für Message Sequence Charts, und der dahinter liegende Compiler ist dann entsprechend auch in C++ geschrieben. Hierbei kann vor allem die Möglichkeiten von MFC nutzen, die die Klassenobjekte als Objekt-Archiv auf die Festplatte schreiben kann, oder einen separat gestarteten Compiler-Prozess über Pipes mit Daten füttern kann.

In anderen Fällen ist C++ das Werkzeug der Wahl, wo man die Möglichkeiten der STL und template-Programmierung gut einsetzen kann. So kann man etwa sehr schön die Simulation einer zustandsgesteuerten Flusssteuerung erstellen. Die formale Definition von Oberklassen kann man leicht in C++ direkt hinschreiben, und verschiedene Ventiltypen ableiten. Das Ergebnis ist (gegenüber Java oder Python) rasend schnell, und erlaubt letztlich, die erstellte objektorientierte Simulation direkt als Steuerungssystem in die zeitkritische Anwendung zu übernehmen. Vorausgesetzt natürlich, das Zielsystem ist fett genug, dass die STL-Bibliothek in den Speicher passt.

Aber man muss ja nicht verzagen - ein C++ Prototyp lässt sich besonders leicht nach C umsetzen. Ich hab sogar mal ein neues GCC Frontend geschrieben, dass bei einer solchen Umsetzung hilft - der seit kurzem bestehende colorgcc macht solche Arbeiten mittlerweile noch einfacher (er gibt eine quer-referenzierte Zwischendarstellung des Codes aus), aber ich hatte noch keine Gelegenheit, dieses auch zu nutzen.