C++ in der Schule

Dieser Artikel behandelt die Frage, ob man C++ als erste Programmiersprache in der Schule einsetzen soll. Seine Erkenntnisse können teilweise aber auch auf andere Bereiche, in denen ausgebildet wird, übertragen werden.

In Frage gestellt wird hier, ob es sinnvoll ist, C++ in allgemeinbildenden Schule und in vergleichbaren Ausbildungen einzusetzen, wenn Teilnehmer mit geringen Vorkenntnissen im Programmieren in vergleichsweise kurzer Zeit (weniger als 100 Stunden) programmieren lernen sollen. Dieser Artikel behandelt nicht die Frage, ob das Erlernen von C++ im Rahmen eines Studiums der Informatik oder für hauptberufliche Programmierer sinnvoll ist. Es wird auch nicht behandelt, für welche Projekte C++ außerhalb des Lehrbereiches eine geeignete Programmiersprache ist.

Abstraktion

C++ ist keine genau definierte Programmiersprache. Viele Details sind absichtlich unbestimmt gelassen, um Compilern Spielraum für Optimierungen zu geben und um Umgebungen und Prozessoren optimal ausnutzen zu können. Insofern ist C++ eine abstrakte Programmiersprache oder eine Menge (Äquivalenzklasse) vieler konkreter Programmiersprachen.

Zum Wertebereich des Datentyps "int" wird in der Norm beispielsweise folgendes festgelegt.

“Plain ints have the natural size suggested by the architecture of the execution environment; ” “that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header <climits>. ”

Der Wertebereich des Datentyps "int" hängt also von der Ausführungsumgebung ab. Um dem Schüler das zu erklären, muß der Begriff der Ausführungsumgebung eingeführt werden und der Schüler muß verstehen, daß sich hinter Makros, wie dem Makro "INT_MIN", Werte verbergen können, die von der Ausführungsumgebung abhängen, aber sonst während der Übersetzung konstant sind. Das ist ein viel höheres Niveau der Abstraktion als bei Programmiersprachen wie Java, wo als Wertebereich des Datentyps "int" der Bereich von –2147483648 bis 2147483647 festgelegt sind. Für viele Schüler kann dieser Unterschied in der Abstraktion schon eine erhebliche Schwierigkeit darstellen, gibt es doch sogar Lehrer, die diese Form der Abstraktion nicht einmal korrekt wiedergeben können (wie man an einigen Veröffentlichungen im Web erkennen kann).

Entsprechende Probleme ergeben sich auch für den Datentyp "char", bei dem es nicht festgelegt ist, ob dieser negative Werte enthalten kann, sowie verschiedene andere Datentypen, die ebenfalls abstrakt definiert sind.

Ein anderes Beispiel für Abstraktion sind uninitialisierte Variablen mit automatischer Speicherdauer, deren Werte undefiniert sind. Schüler sind kaum in der Lage, diesen Sachverhalt richtig wiederzugeben und bezeichnen die Werte statt dessen bestenfalls als „zufällig“ (obwohl es sich natürlich nicht um zufallsverteilte Werte handelt). Konkrete definierte Anfangswerte (wie der Anfangswert 0 für numerische Variable), wie es sie in manchen Programmiersprachen, wie beispielsweise in BASIC, gibt, sind deswegen verständlicher, weil sie konkret vorstellbar sind.

Auch bei Standardaufrufbarem kann man die höhere Abstraktion von C++ im Vergleich mit beispielsweise Java erkennen: In Java ist das Ergebnis der Standardmethode "java.lang.System.currentTimeMillis" vom Datentyp "long", einem bekannten ganzzahligen Datentyp mit einem genau festgelegten Wertebereich, und gibt die Millisekunden seit der Mitternacht (UTC) des 1. Januar 1970 an. In C++ ist das Ergebnis der Standardfunktion "std::time" vom Datentyp "std::time_t", über den nichts weiter festgelegt ist, als daß es ein arithmetischer Typ ist, der einen implementationsdefinierten Wertebereich hat. Die Darstellung (Codierung) des Ergebnisses von "std::time" ist aber vollkommen unspezifiziert, der erhaltene Wert darf also von einem Programm nicht direkt interpretiert werden, etwa als eine bestimmte Zahl von Millisekunden oder ähnliches (er kann aber mit bestimmten anderen Standardfunktionen weiterverarbeitet werden). Auch hier ist es wieder schwer, Schülern zu vermitteln, daß eine Zeit durch einen arithmetischen Datentyp dargestellt wird, über dessen Wertebereich nichts weiter ausgesagt werden kann, und daß der von "std::time" erhaltene Zeitwert nicht irgendwie weiter erklärt oder beschrieben werden kann (etwa als Millisekunden seit dem 1. Januar 1970 wie in Java ). Solch ein „abstrakter Wert“ ist eben schwerer vorstellbar und unanschaulicher als eine long-Zahl mit den Millisekunden seit dem 1. Januar 1970.

Trust the programmer

In C++ wird getreu dem Motto “Trust the programmer ” vielen Notationen und Kombinationen von Sprachelementen ein Sinn gegeben, die in anderen Sprachen als Fehler zurückgewiesen werden würden.

Eine Schreibweise wie z.B. in dem Anweisungsteil "if( x = f() )", wird von einem erfahrenen Programmierer meistens genau so gemeint, wie sie geschrieben ist, während sie Schülern öfter als Fehler unterlaufen kann, wenn eigentlich ein Vergleich durchgeführt werden soll. Da eine Zuweisung an dieser Stelle in C++ aber vollkommen legal ist, erhält ein Schüler bei versehentlicher Verwendung oft keine Warnungsmeldung.
Die Anweisung "double x =( 2,7 );" ist vollkommen korrekt. Allerdings hat das Objekt "x" danach den Wert "7". Ein Schüler, der "2.7" meint, würde in vielen anderen Programmiersprachen eine hilfreiche Fehlermeldung erhalten. In C++ verwendet er ungewollt den Komma-Operator. Wer glaubt, der Wert des Ausdrucks "3,0" sei der Wert "3", wird hingegen durch die Ausgabe der Anweisung "::std::cout << 3,0 << '\n';" nicht eines Besseren belehrt, obwohl der Ausdruck dieser Anweisung ganz anders zu interpretieren ist als in Unkenntnis der Priorität der verwendeten Operatoren vielleicht vermutet wird. Nach der Anweisung "phi=3,14159;" hat das double-Objekt "phi" im allgemeinen den Wert 3.
Natürlich ist auch der Ausdruck "a[ x, y ]" (für geeignet deklarierte Bezeichner) vollkommen korrekt—Nur wird oft erwartet, daß er etwas anderes bedeutet, als es tatsächlich der Fall ist, wenn jemand auf diese Weise zwei Indizes eines zweidimensionalen Feldes angeben will.
Die Anweisung "{ if( x < 8 ); std::cout << 8; }" gibt den Text "8" unabhängig von der if -Bedingung aus und enthält daher eine recht sinnlose if -Anweisung, die aber von C++ -Implementationen nicht als Fehler gemeldet werden muß, da sie syntaktisch vollkommen korrekt ist. (Ähnliche Beispiele lassen sich mit manchen Schleifenanweisungen schreiben.)
Die Verwendung eines Funktionsnamens als Ausdruck ist ohne den Aufrufoperator möglich, bedeutet aber etwas ganz anderes als einen Aufruf der Funktion. Der Schüler kriegt also meistens keine Warnungsmeldung, wenn er eine Pseudozufallszahl mit "std::cout << std::rand << '\n';" ausgeben will und dabei den Aufrufoperator vergißt.
Wenn ein Gleitkommaausdruck an eine Funktion übergeben wird, die einen ganzzahligen Wert erwartet, dann werden die Nachkommastellen stillschweigend abgeschnitten, so ist der Wert des Ausdrucks "std::isalpha( 64.9 )" beispielsweise dem Wert des Ausdrucks "std::isalpha( 64 )" gleich. In einigen solcher Fälle kann allerdings die Angabe einer Gleitkommazahl ein Irrtum des Programmierers sein.

Für Anfänger ist es eher schädlich, daß C++ so viel akzeptiert, weil es dazu führt, daß auch viele irrtümliche Formulierungen mit einer anderen als der vom Autor beabsichtigten Bedeutung oder mit implementationsspezifischem Verhalten ohne irgendeine Fehlermeldung oder Warnung akzeptiert werden. Schüler können solche Fehler auch finden und verstehen, es kostet sie aber mehr Zeit als in Sprachen, die weniger Freiheiten erlauben und daher bei solch einer Formulierung sofort eine Fehlermeldung erzeugen würden. Diese Zeit fehlt dann wieder, um sich mit der Methodik des Programmierens zu beschäftigen. Schüler lernen unter Umständen dabei viele Details einer speziellen Programmiersprache aber weniger allgemein nützliches Programmierwissen.

Viele Programmiersprachen schränken die Möglichkeit der Kombination von Sprachelementen stärker ein und machen damit mehr Abweichungen als Fehler diagnostizierbar. In Pascal oder VBA ist eine Zuweisung als Ausdruck in einer Verzweigungsanweisung beispielsweise gar nicht erlaubt. Man kann sagen, das Motto “trust the programmer ” gelte eher für erfahrene Programmierer als für Schüler.

Speicherverwaltung

C++ enthält wegen der Optimierung auf Laufzeiteffizienz auch keine automatische Verwaltung der Belegung typisierter Speicherbereiche. Dadurch muß der Schüler sich beim dynamischen Aufbau von Datenstrukturen immer auch um die Speicherverwaltung kümmern, um Speicherlecks zu verhindern. Eventuell durch Programmierfehler auftauchende Speicherlecks werden von der Sprache nicht als Diagnose gemeldet, sondern müssen mühevoll gesucht werden. Es entsteht dadurch der Eindruck, daß der Aufbau und die Verwendung von Datenstrukturen ein sehr schwieriges Geschäft sei.

Natürlich kann es lehrreich sein, die Speicherverwaltung zu erlernen. Doch handelt es sich dabei um eine recht technische und abstrakte Art der Verwendung einer Programmiersprache zur Lösung von Problemen, die man ohne die Sprache gar nicht hätte. Schüler werden zunächst durch Problemstellungen, die anwendungsnäher sind oder anschauliche Resultate produzieren, leichter motiviert werden können.

Sprachen, wie Perl, Java, LISP oder VBA enthalten eine automatische Verwaltung der Lebenszeit von Speicherbereichen (einen “garbage collector ”), die dazu führt, daß der Programmierer sich auf eine gegebene Problemstellung konzentrieren kann, ohne befürchten zu müssen, einen Zeiger auf unbelegten Speicher zu verwenden oder nicht mehr benötigten Speicher nicht freigegeben zu haben. In solchen Sprachen ist der Aufbau auch von dynamischen Datenstrukturen einfacher. Ein großer Teil der Probleme, die Zeiger in C++ bereiten, sind Schwierigkeiten mit der Speicherverwaltung. Es mag auch immer wieder leistungsstärkere Schüler geben, die sich mit Vergnügen der Herausforderung der Ressourcenverwaltung in C++ widmen. Für alle anderen Schüler kann aber die Notwendigkeit zur Verwaltung von Speicher das Programmieren so sehr erschweren, daß sie die Beschäftigung damit eher aufgeben wollen.

Effizienz

Die Speicherverwaltung fehlt in C++ vor allem, weil sie Laufzeit kostete. Viele andere Mühen nimmt ein C++ -Programmierer nur aus einem Grund auf sich: Um die Laufzeiteffizienz des geschriebenen Programms zu steigern. Dieser Gedanke durchdringt die Gestaltung der gesamten Sprache bis hin zur generischen Programmierung. Das Ziel ist die Erzeugung möglichst schneller Programme.

Um dieses Zieles willen, werden dem Programmierer auch noch viele Techniken maschinennaher Programmierung ermöglicht. Auf die meisten Tests zur Absicherung des Programms und zur Fehlerdiagnose während Laufzeit wird verzichtet, weil diese ja Zeit kosten könnte.

Es gibt viele Schüler, die mit den allereinfachsten Aspekten des Programmierens, wie der Zuweisung eines Zahlenwertes an eine numerische Variable, schon große Schwierigkeiten haben. Ein erfahrener Programmierer vermag sich nicht immer in die Gedankenwelt eines Schülers zu versetzen, für den manchmal das Verständnis eines Programms mit Variablen, deren Werte erst zur Laufzeit eingelesen werden und nicht bereits beim Schreiben des Programms festgelegt werden, schon einen erheblichen Akt der Abstraktion darstellt.

Daher sollte die Programmiersprache diesen Schülern nicht noch zusätzliche Steine durch weitere Komplikationen in den Weg legen, für die in der Schule noch gar keine Notwendigkeit besteht. Das Erreichen höchster Geschwindigkeit der erzeugten Programme muß in der Schule nicht vorrangiges Ziel sein. Nur wenige haben das Autofahren zuerst mit einem Formel-1-Rennwagen erlernt.

Umfang

C++ ist, verglichen mit Sprachen wie C oder Pascal, eine sehr umfangreiche Programmiersprache. Der Satz “C++ is already too large and complicated for our taste ”[1] stammt immerhin von Bjarne Stroustrup, dem Erfinder der Sprache, und der ähnlich klingende Ausspruch “C++ is too complicated. At the moment, it's impossible for me to write portable code that I believe would work on lots of different systems ”[2] von Donald E. Knuth.

Will man Schülern ohne Vorkenntnissen im Programmieren eine Programmiersprache als Lernsprache zumuten, die ihrem eigenen Erfinder bzw. dem bedeutendsten Computerwissenschaftler unserer Zeit als zu umfangreich und kompliziert erscheint? C++ ist ein Gewirr verschiedener Sprachkonstrukte aus drei Jahrzehnten der Programmierung, das man so heute nicht mehr festlegen würde, ginge es um die Gestaltung einer neuen Sprache. Neben den empfohlenen Sprachbestandteilen stehen Hinterlassenschaften, die nur noch deshalb in der Sprache enthalten sind, weil C ‑ oder C++ -Programmierer dies so gewohnt sind oder damit ältere Programme noch laufen können.

Um den Schülern dies nicht zuzumuten, könnte man versuchen, nur einen ausgewählten Teil der Sprache zu lehren. Doch da die verschiedenen Sprachbestandteile unbeschränkt aufeinander Bezug nehmen können und dies auch tun, wird solch ein Versuch oft scheitern.

Beispielsweise liegt der Gedanke nahe, zur Textverarbeitung nur noch die Dienste der Klasse "std::string" in Anspruch zu nehmen und die Verwendung von Zeigern auf Objekte vom Datentyp "char" gar nicht zu erwähnen. Entsprechend bietet es sich zunächst auch an, nur die Standardschablonenklasse "vector" zu lehren und keine klassischen Datenfelder mehr. Doch dies kann spätestens dann nicht mehr durchgehalten werden, wenn die Verwendung des zweiten Parameters der Funktion "main" behandelt werden soll (der ist nämlich vom Typ "char **"). Auch an verschiedenen anderen Stellen werden Zeiger und Felder benötigt, so daß dann insgesamt zwei verschiedene Sprachmittel für ähnliche Ziele erlernt werden müssen. Die dafür aufgewendete Zeit fehlt dann wieder für die Behandlung allgemein nützlicher Methoden der Programmierung.

Auch der Präprozessor kann nicht einfach verschwiegen werden, denn zur Verwendung der Pseudozufallszahlen wird auch ein Verständnis des Bezeichners "RAND_MAX" nötig sein, bei der Definition von Kopfdateien ist es nötig den Direktiventyp "#ifdef" (zur Verhinderung mehrfacher Einbindung) und den Direktiventyp "#include" zu verwenden. Mit dem Präprozessor lernen die Schüler aber wieder einmal ein Gebilde kennen, daß so nur in C und C++ verwendet wird und nicht dem Erlernen allgemeiner Programmiermethodik dient. In C++ werden zudem viele Funktionen des Präprozessor durch das Einfügen von Funktionen (mit dem Schlüsselwort "inline") oder Schablonen ersetzt, so daß der Schüler auch mit dieser nur historisch zu erklärenden Redundanz der Implementierung konfrontiert wird.

Auch die generative Programmierung kann nicht „versteckt“ werden, da sie beim Einsatz vordefinierter Standardklassen, wie etwa der Standardschablonenklasse "vector" zumindest angewendet werden muß. Aber mit der speziellen Art generischer Programmierung in C++ lernt der Schüler wieder etwas ganz C++ -spezifisches. Doch es ist fraglich, ob schon in der Schule die intensive Beschäftigung mit speziellen Eigenschaften, die es so nur in einer Programmiersprache gibt, viel Zeit in Anspruch nehmen sollte.

Zum Erlernen des Programmierens reicht ein Datentyp für Gleitkommazahlen und ein Datentyp für ganze Zahlen vollkommen aus. Diese könnten etwa dem Datentyp "double" und dem Datentyp "int" von C++ entsprechen. Die vielen zusätzlichen Zahlen-Datentypen, wie der Datentyp "float", wie der Datentyp "long double", der Datentyp "unsigned int", der Datentyp "long", der Datentyp "unsigned long", der Datentyp "short", der Datentyp "unsigned short", und gewissermaßen auch der Datentyp "char", der Datentyp "signed char" und der Datentyp "unsigned char" dienen eher der Steuerung der Effizienz oder der Verwendung maschinenspezifischer Datenstrukturen. Sie können aber auch schlecht einfach verschwiegen werden, wenn schon C++ gelehrt wird, weil sie bei verschiedenen Schnittstellen der Standardbibliothek eine Rolle spielen oder einfach zum Verständnis fremder Programme bekannt sein sollten. Dabei muß der Schüler also verschiedene Zahlendatentypen erlernen, die zum Verständnis der Methodik des Programmierens in dieser Vielfalt nicht vorrangig benötigt werden und wird wiederum mit verschiedenen abstrakten Definition der Beziehungen zwischen den verschiedenen Zahlendatentypen konfrontiert.

Schließlich gehört zum Erlernen einer Programmiersprache auch das Aneignen der Fähigkeit, vorgegebene Übersetzungseinheiten der Sprache lesen zu können, denn in der Praxis sind oft vorgegebene Programme zu verstehen und anzupassen und nicht immer nur neue Programme zu schreiben. Um darauf vorbereitet zu sein, muß ein Programmierer dann auf jeden Fall den ganzen Sprachumfang kennen oder wenigstens in der Lage sein, eventuelle Wissenslücken schnell zu schließen. Das ist bei vielen kleineren Programmiersprachen natürlich einfacher zu bewältigen.

Systemschnittstellen

Obwohl C++ als Programmiersprache schon recht umfangreich ist, wurden doch bewußt Schnittstellen für viele System nicht für die Sprache normiert. Dadurch sollen die Voraussetzungen für C++ -Implementationen so vermindert werden, daß C++ auf möglichst vielen Plattformen implementiert werden kann. Gleichzeitig wäre ein noch größerer Sprachumfang natürlich auch noch schwieriger zu handhaben.

Eine Konsequenz dieser Entscheidung ist es aber, daß beim Unterrichten der Programmiersprache C++ eine bestimmte Schnittstelle zu vielen für Schüler interessanten Systemen nicht vorausgesetzt werden kann.

Als Beispiel für ein solches System sei zunächst eine graphische Benutzeroberfläche genannt. Die recht portable Programmiersprache Java enthält beispielsweise mit Swing eine Schnittstelle und Implementation, über die eine graphische Benutzeroberfläche mit den Mitteln der Programmiersprache selber definiert werden kann.

In C++ gibt es in dieser Hinsicht nur die Alternative, entweder auf die Programmierung graphischer Benutzerschnittstellen ganz zu verzichten oder spezielle zusätzliche und nicht mit C++ portable APIs zu verwenden. Bei Verzicht auf die Programmierung graphischer Benutzeroberflächen sind Schüler oft enttäuscht und demotiviert, weil sie die Textoberfläche von C++ -Programmen als veraltet oder minderwertig empfinden und natürlich die von ihnen außerhalb des Unterrichts benutzten Programme mit einer graphischen Oberfläche als vorbildliche „richtige Programme“ empfinden. Wenn jedoch im Unterricht ein spezielles API gelehrt wird, wie z.B. das Windows -API, dann wird damit nichtportables Spezialwissen zur Programmierung eines bestimmten Betriebssystems gelehrt. Falls die Programmiersprache C++ auf dem Lehrplan steht, würde damit auch das Thema verfehlt werden, weil die Programmierung des Windows-API nun einmal nicht mehr direkt zum Thema C++ gehört.

Hinzu kommt noch, daß die Verwendung der zu C++ gehörenden Standardströme für das Einlesen und Ausgeben über die Konsole auch schon einige Schwierigkeiten bietet, wenn interaktive Programme einigermaßen sicher geschrieben werden sollen, so daß auch auf fehlerhafte Eingaben [wie der Eingabe eines Textes, wenn eine Zahl erwartet wird] sinnvoll reagiert wird. Das Verarbeiten einzelner Tasten ist in der Regel nicht mit der Standardbibliothek möglich, was dazu führt, daß nicht einmal solch schöne klassische Echtzeitspiele wie die „Mondlandung“ damit portabel programmiert werden können.

Eine motivierende Rückmeldung für Schüler kann die Steuerung eines beweglichen Systems in einer kleinen, bildlich dargestellten, „Welt“ sein. Eine einfache, kleine Lernsprache, die Programmierung durch eine bewegliche, programmierbare „Schildkröte“ veranschaulichen kann, ist Logo, z.B. http://www.softronix.com/logo.html. Aber auch für Java gibt es solche „Schildkröten“ , z.B. http://www.swisseduc.ch/informatik/karatojava/javakara/index.html.

Das gleiche Bild bietet sich, wenn man Java und C++ hinsichtlich der Internet-Programmierung oder der Datenbankprogrammierung vergleicht: Auch hier bietet Java wieder standardisierte Schnittstellen innerhalb der Sprache, die den Weg zu einigen interessanten Programmierprojekten mit den portablen Mitteln der Sprache selber eröffnen, die so mit C++ nicht möglich sind. Ähnlich fällt der Vergleich mit Perl aus: Viele Anforderungen lassen sich mit Perl relativ portabel bewältigen, etwa mit dem Zugriff auf Dateiverzeichnisse, Internetdaten oder Datenbanken zusammenhängende Aufgaben. Ein typisches, nützliches Anwendungsprogramm, das beispielsweise mit einer graphischen Oberfläche Informationen von einer Webseite holt und in eine lokale Datenbank schreibt, läßt sich so mit Java oder Perl einigermaßen portabel realisieren; in C++ ist dies mit den Mitteln der Sprache nicht möglich.

Natürlich spricht dies alles nicht gegen den Einsatz der Programmiersprache C++ durch erfahrene Programmierer in Aufgabenbereichen, für die die Sprache sinnvoll ist. Zur Programmierung bestimmter Systeme werden fortgeschrittene Programmierer möglicherweise bewußt die Entscheidung treffen, auf Portabilität zu verzichten oder Techniken einsetzen, um durch Definition eigener Schnittstellen portable und nichtportable Programmteile zu entkoppeln.

Für Schüler ist es aber sehr motivierend, wenn die erlernte Programmiersprache selber einige Schnittstellen zu Systemen (z.B. zu graphischen Benutzeroberflächen, Internet-Sockets, Dateisystemen) enthält, mit denen sich einige interessante Anwendungen mit den Mitteln der Sprache realisieren lassen, ohne daß nichtportable APIs verwendet werden müssen. Sprachen wie Perl und Java bieten hier einiges, das zusammen mit der Vereinfachung durch die automatische Speicherverwaltung schneller zu den für die Schüler so wichtigen Erfolgserlebnissen führt.

Ausgabeoperatoren

Schon für ein einfaches Programm zur Ausgabe des Textes „Hallo, Welt“ in C++ werden die Ausgabeoperatoren "<<" verwendet. Hinter diesen Operatoren versteckt sich schon eine erhebliche Komplexität.

Um den Ausdruck "std::cout << c++ << c++" zu verstehen, muß der Schüler schon wissen, daß Operatoren Werte und Wirkungen haben können, daß der hier verwendete Operator linksassoziativ ist und welchen Wert und welche Wirkung der linke Teilausdruck mit dem Operator "<<" hat, daß die Reihenfolge der Auswertung von Operanden ohne Sequenzpunkte aber undefiniert ist und welche Konsequenzen dies in diesem Fall haben kann (so daß man solch eine Formulierung meiden sollte, was man aber erst einmal erlernen muß). Auch muß das Konzept der Überladung eines Operators für verschiedene Datentypen behandelt werden. Um eine bestimmte Feldbreite einzustellen, kann beispielsweise die Funktion "std::setw" verwendet werden, deren Ergebnistyp von C++ nicht weiter bestimmt wird. Der Schüler muß beachten, daß bei Verwendung von "std::setw" eine bestimmte Kopfspezifikation einzubinden ist. Der Ausdruck "std::cout << std::setw( 1 )" führt nun nicht etwa zur Ausgabe des Wertes von "std::setw( 1 )", sondern zu einer Veränderung des Zustandes des Ausgabestromes, während der Ausdruck "1 << 4" wieder etwas ganz anderes bedeutet. Der Wert des Ausdrucks "std::cin >> foo" ist "std::cin", aber wieso dieser auch in der Anweisung "if( std::cin >> foo )bar();" sinnvoll verwendet werden kann, ist wieder nicht ganz einfach zu erklären.

In dem Text "std::vector<std::vector<int>> v;" wird das Zeichenpaar ">>" von einer C++ -Implementation allerdings ebenfalls als Operator gelesen, obwohl es das hier wohl nicht sein soll. Von einem C++ -Programmierer erwartet man eben, das zu bemerken und zu wissen, wie dieses Problem umgangen werden kann.

Diese vielfältigen Zusammenhänge, in denen der Operator "<<" oder der Operator ">>" oft eine andere Bedeutung hat, sind eine teilweise recht elegante Lösung der Formulierung von Ein- und Ausgabeoperationen, die aber den Schülern oft zunächst nicht anders erklärt werden können, als der angesehene Autor Bruce Eckel des Lehrwerkes “Thinking in C++ ” dies tat, indem er beispielsweise zur Verwendung von "std::cin" als Ausdruck mit dem Datentyp "bool" schrieb “For now you'll have to accept that when you use an input stream object in this context, the right value is safely, correctly and magically produced (…) ”. Das bedeutet, daß Schüler von Anfang an mit Programmteilen konfrontiert sind, die sie nicht vollständig verstehen und ihnen so die Nachricht vermittelt wird „das kann man nicht richtig verstehen“, wenn nicht viel Zeit mit der Erklärung aller möglichen soeben erwähnten Details der Programmiersprache zugebracht werden soll.

Experimentelle Aspekte

Einige Teile von C++, wie die Art und Weise der generischen Programmierung, kann man als experimentell bezeichnen, da sie mit der C++ -Norm eingeführt wurden und von den meisten Implementation im Jahre 2002 auch noch nicht korrekt umgesetzt wurden. Abgesehen davon, daß dieser Zustand selber für Schüler irritierend ist, ist es auch nicht Aufgabe der Schule solche neuartigen experimentellen Aspekte im Rahmen einer Einführung in das Programmieren zu lehren. Schon bei der Verwendung der Schablonenklasse "vector" wird man aber mit einigen Aspekten der generischen Programmierung konfrontiert. Diese kann also nicht einfach verschwiegen werden.

Strukturierte Programmierung

C++ ist keine strukturierte Programmiersprache, denn Blöcke mit genau einem Eingang und einem Ausgang werden von der Sprache nicht unterstützt, weil viele Funktionen mitten in einem Block eine Ausnahme erzeugen können, die zum Verlassen des Blocks führt. Die Berücksichtigung sprungartiger Ausnahmen (“exceptions ”) ist für den Programmierer unumgänglich, weil die Sprache selber in ihren Standardfunktionen solche erzeugen kann.

Herb Sutter nennt zum Beispiel folgende Funktionsdefinition.

EvaluateSalaryAndReturnName

String EvaluateSalaryAndReturnName( Employee e )  { 
    if( e.Title() == "CEO" || e.Salary() > 100000 ) 
    { 
      cout << e.First() << " " << e.Last() 
           << " is overpaid" << endl; 
    } 
    return e.First() + " " + e.Last(); 
  }

Er wirft dann die Frage auf, wie viele verschiedene Ausführungspfade durch diesen Code bei einem Aufruf der Funktion möglich sind. Es stellt sich heraus, daß es drei verschiedene klassischen Pfade in Abhängigkeit von den Bedingungen und gemäß der Definition des Operators "||" und der if-Anweisung gibt. Es gibt aber 20 weitere Pfade, die davon abhängen, welcher Operator und welche Funktion wann eine Ausnahme erzeugt.

Strukturierte Vorgänge wie „(Schritt 0 :) Versuche, eine Datei zu öffnen; (Schritt 1 :) Falls die Datei geöffnet werden konnte, dann (Schritt 1A :) verwende die Datei und (Schritt 1B :) schließe die Datei anschließend wieder.“ kann man in C++ nicht so formulieren. Denn eine Ausnahme beim Schritt 1A könnte dazu führen, daß Schritt 1B niemals ausgeführt wird.

Damit enthält jedes C++ -Programm eine gewaltige versteckte Komplexität der Ablaufsteuerung: Ein Programmierer muß für alle 23 Pfade des obigen Beispiels sicherstellen, daß der Programmzustand integer bleibt und das Programm sich wie gewünscht verhält. Daß es für Schüler schwierig ist, sich all diese Pfade vorzustellen, kann man sich wohl denken.

Zur Beherrschung der Ressourcenverwaltung angesichts der Ausnahmen kann das Handwerk der ausnahmesicheren Programmierung eingesetzt werden. Die Technik der ausnahmesicheren Programmierung, wie sie etwa von Herb Sutter gelehrt wird, erlaubt die Beherrschung der gewaltigen versteckten Komplexität der Abläufe aufgrund von verschiedenen Ausnahmen durch eine diszipliniertes Herangehensweise, stellt aber für Schüler zunächst eine erhebliche Herausforderung dar und ist schwer zu motivieren und teilweise auch wieder sehr C++ -spezifisch.

Die Frage der ausnahmesicheren Programmierung wird also wahrscheinlich im Unterricht einfach ignoriert werden, beispielsweise indem weiterhin strukturiert programmiert wird, so als ob es gar keine Ausnahmen gäbe. So wird von Anfang an ein in C++ mangelhafter Programmierstil eingeübt, der nicht sicher mit Ausnahmen umgeht und erhebliche Schäden anrichten kann (z.B. in Zusammenhang mit Ressourcenverwaltung).

Die C++ -gemäße Programmierung führt aber in der Schule auch wieder zu Problemen: Zunächst einmal muß man viele Grundsätze und Vorteile der strukturierten Programmierung aufgeben. Schüler könnten im Schritt 1A eine Ausnahmebehandlung (mit dem Schlüsselwort "catch") einführen, um sicherzustellen, daß Schritt 1B garantiert ausgeführt wird. Dieses Verfahren wird aber wegen seiner Mängel von erfahrenen Programmierern abgelehnt, die statt dessen die Vorgehensweise RAII (“resource acquisition is initialization ”) verwenden. Diese hat aber in der Schule wiederum Nachteile: Zum einen ist sie in einigen Fällen erst anwendbar, nachdem Schüler mit der Definition von Klassen vertraut sind. Hinzu kommt es, daß RAII Destruktoren verwendet, die es so bei den populären Sprache nur in C++ gibt. Damit lernen die Schüler also dann anstelle der allgemeinen Grundbegriffe der strukturierten Programmierung die spezielle, so nur in C++ anwendbare, Technik RAII und andere Techniken der ausnahmesicheren Programmierung in C++.

Verfügbarkeit der Spezifikation

Gerade bei der durch eine Spezifikation (Norm) bestimmten Sprache C++ ist es wichtig, daß der Programmierer jederzeit Zugriff auf die Spezifikation hat, um in Fragen zur Sprachdefinition die maßgebliche Auskunft zu erhalten. Die meisten Lehrbücher oder Nachschlagewerke geben die Norm nur unvollständig wieder, geben veraltete Versionen der Norm wieder und/oder enthalten Fehler und Abweichungen gegenüber der Norm. Da die Norm aber nicht einfach kopiert werden darf und gegen Bezahlung erworben werden muß, ist sie für den Schulunterricht und für einzelne Schüler schwerer zugänglich als die Spezifikationen mancher anderen Programmiersprachen, wie beispielsweise die über das Internet kostenlos verfügbare Java Language Specification und Java API Specification.

Doch selbst jemand, der den Aufwand der Beschaffung der C++ -Norm ISO/IEC 14882:1998(E) auf sich genommen hat, verfügt damit noch nicht über alle notwendigen Quellen, weil diese Norm wichtige Aspekte der Sprache (etwa hinsichtlich der Ausgabeformatierung oder großer Teile der Standardbibliothek) nicht selber enthält, sondern sich auf die C -Norm ISO/IEC 9899:1990 Programming languages – C bezieht. Für C gibt es aber mittlerweile eine neue Norm ISO/IEC 9899:1999 (E). Die Lieferanten sind daher der Meinung, daß die vorherige C -Norm nicht mehr aktuell ist und bieten sie daher kaum noch an. Daher ist ein wesentlicher Teil der Spezifikation der Programmiersprache C++ gar nicht oder nur noch unter großem Aufwand erhältlich oder einsehbar.

Da andererseits bestimmte Teile von C++ (wie das Schlüsselwort "export") von noch praktisch keinem Compiler korrekt implementiert werden, kann man sagen: Die Sprache ist teilweise so neu, daß es noch keine Implementation gibt, und teilweise so alt, daß es schon keine Spezifikation mehr gibt.

Hinzu kommt noch, daß die beiden relevanten Normen in Englisch verfaßt sind. Tatsächlich werden auch viele dort verwendete Fachbegriffe nicht im Englischunterricht behandelt, so daß eine flüssige Lektüre den Schülern tatsächlich erschwert ist.

Beispiele einzelner Irritationen

In C++ gibt es eine lange Liste von Wissen um einzelne technische Details, das der Programmierer benötigt, die aber für das Erlernen der Methodik des Programmierens keinen Nutzen haben.

Will man einem Schüler eine Programmiersprache zumuten, in der der Wert des Ausdrucks "-1 < 3000000000" in manchen Implementationen gleich dem Wert "false" ist und der Wert des Ausdrucks "-1 < 2000000000" gleich dem Wert "true" ist? (Hier wurde die Situation am Beispiel einer Implementierung dargestellt, bei der ein int -Wert 32 Bit hat, bei anderen Implementationen kann dieser Effekt mit anderen Zahlenwerten beobachtet werden.)
Innerhalb eines Klassenspezifizierers kann eine statische ganzzahlige Konstante mit der Eintragsdeklaration "static int const i = 7;" definiert werden. Die Eintragsdeklaration "static double const d = 7.0;" kann hingegen nicht verwendet werden. Solche Eintragsdeklarationen im Klassenspezifizierer sind eben nur für ganzzahlige Konstanten erlaubt.
Viele aktuelle Compiler setzen einzelne Aspekte des C++ -Standards noch nicht richtig um. In Schulen sind zudem teilweise noch ältere Compiler installiert, die noch deutlich vom Standard abweichen. Der Schüler muß dann teilweise falsche Programme schreiben, damit sie vom Compiler akzeptiert werden, eine didaktische Katastrophe.
Die Anweisung "T t(u);" definiert eine Variable "t" vom Typ "T" mit dem Anfangswert "u", während die Anweisung "T t();" nicht etwa eine Variable "t" vom Typ "T" definiert, für die kein Anfangswert vorgegeben wird, sondern eine Funktion "t" deklariert, die keine Argumente akzeptiert und einen Rückgabewert vom Typ "T" hat. Auch die Deklaration "std::vector<int> v( std::istream_iterator<char>( cin ), std::istream_iterator<char>() );" ist keine Variablendefinition, sondern eine Deklaration einer externen Funktion "v" (der Bezeichner "cin" ist darin ein Parametername). Es ist also leicht möglich, eine lokale Funktionsdeklaration zu schreiben, wenn eine Variablendefinition beabsichtigt ist.
Während alle anderen Vektoren Container des angegebenen Datentyps sind, ist "vector<bool>" trotz seines Namens kein Container und enthält keine "bool"-Objekte.
Koenig Lookup (argument-dependent name lookup (ADL )) ist ein so nur in C++ implementiertes Verfahren zur Namensauflösung, das von einigen älteren Compilern nicht richtig implementiert wird. Wenn Programmierer es nicht kennen, werden sie aber früher oder später vom Verhalten ihres Programmes überrascht werden.
Obwohl aus den Implementationsdateien (mit der Endung ".c" oder der Endung ".cpp") alle relevanten Informationen entnommen werden könnten (was in vielen anderen Sprache auch entsprechend geschieht), muß der C++ -Entwickler Teile der Beschreibung von Schnittstellen noch einmal in Deklarationsdateien (mit der Endung ".h" oder der Endung ".hpp") wiederholen. Bei Änderungen an einer Stelle sind dann parallele Änderung an einer anderen Stelle nötig. Die Aufteilung von Programmteilen auf Implementationsdateien und Deklarationsdateien wird oft durch technische Notwendigkeiten bestimmt und muß vom Programmierer aufwendig erlernt werden, während dieses Thema in anderen Sprachen ganz entfällt, wo solch eine Aufteilung nicht existiert.

Siehe auch

<721269 Erklärung spezifikationsdefinierter formaler Sprachen

Quellen

[1] From: bs@alice.att.com (Bjarne Stroustrup); Newsgroups: comp.lang.c++,comp.std.c++; Subject: Re: C++ Language Extensions; Message-ID: <25698@alice.att.com>

[1] http://tex.loria.fr/litte/knuth-interview, Interview mit Donald E. Knuth vom 1993-12-07.

Meinungen zu C++ als Lernsprache

Dealing with complexity, by Charlton Wilbur

When I was in college, the introductory course was taught in Pascal, which was used as a lingua franca for discussions of algorithms. Aside from that, students were expected to be smart enough to learn the syntax of a language on their own, and one of the early upper-level classes was a comparative study of programming languages.

With the web craze and the dot-com boom and bust, a lot of pressure was applied to that curriculum to become “industry-relevant”; rather than having a half-dozen majors, most of whom had mathematics backgrounds, they had several dozen, and most of them for mercenary reasons: some idiot guidance counselor said to them, “There's a lot of money in computers, mmkay?”

As a result of this pressure, Pascal, which was nearly perfect for teaching introductory concepts, was replaced by C++, which was not. Rather than having a solid foundation which made C++ easy to learn (at least comparatively, for something that gargantuan and complicated), the students had a shaky foundation that made other things impossible to learn. But they had an "industry-relevant" programming language to put on their resumes, so their poor preparation and lack of foundation didn't seem to bother them.

As for myself, it wasn't until I got to play extensively with Smalltalk, Objective-C, and LISP that I realized just how badly broken C++ is. (C isn't broken; it's an elegant solution to the problem it was invented to solve, but it's used in an awful lot of places where it's a poor choice of tool.)

Charlton

Usenet Source description

From: Charlton Wilbur 
Message-ID: <87oezm7eoa.fsf@mithril.chromatico.net> 
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super 
Subject: Re: Dealing with complexity 
Date: Tue, 22 Jul 2003 15:42:06 GMT

Java vs C++, by Matthias Blume and Shinji Ikari

Shinji Ikari writes:

Learning C++ is equivalent to studying to be a NASA test pilot. Its incredibly fast and effective, but takes years to master the arcania and things tend to blowup in your face if you're not very careful.

François-René Rideau :

Like Perl, C++ is a Swiss army chainsaw of a programming language. Unlike Perl, it's got all the blades simultaneously and permanently cast in a fixed half-open position. Don't turn it on.

http://fare.livejournal.com/135078.html

Matthias Blume responds:

I would rather compare it to learning how to drive a racecar: yes, it can be fast. Most people tend to drive it off track right away. Some people die in it. The skills you acquire by learning it are only marginally related to what you need in the real world. (In the case of cars, you learn nothing about traffic rules, defensive driving, etc.) The activity is (or, in the case of C++, should be) illegal except in specially marked areas that are protected from the rest of the world, and of which the rest of the world is protected from. The activity is also not very useful in practice: the vehicle goes really fast for only short periods of time. Even very skilled drivers cannot stop the vehicle from blowing up or falling apart after a few hundred miles unless extremely expensive maintenance is applied constantly.

Usenet Source description

From: Matthias Blume 
Message-ID: <m1he5d2tid.fsf@tti5.uchicago.edu> 
Newsgroups: comp.theory.cell-automata,comp.lang.java.advocacy,comp.lang.scheme,comp.lang.misc 
Subject: Re: Cellular automata benchmarks: Java vs C++ vs Java vs C++ 
Date: 23 Jul 2003 09:43:38 -0500

Some comments, by Marco van de Voort

Regarding this page Marco van de Voort writes:

I read it (I'm interested in the subject of language choice from an educational perspective) Some comments:

the article reads as an advocacy type meant to put C++ down, maybe it isn't meant as such, but it feels like it to me. Some balancing here and there would help. Specifically:
Try to detail for each paragraph (argument against C++ ) for which kind of student (education type and level), Requirements for CS students are totally different then for managers that want to do some calculations. This is particularly the case for the memory management paragraph. I wouldn't want to employ a CS student that can't handle manual storage allocation, or somebody doing a electronics course (or CS in the direction of embedded) who doesn't know anything about internals.
Try to detail if the argument is mainly a problem for an introductionary course or in general. (here and there are some references to beginners) The choices for an introductionary course is totally different from an advanced course.
I specially don't like the memory-management paragraph. While manual management might be undesirable from a productivity and safety perspective, that is a different discussion. I wouldn't say it is unsuitable for teaching. (Pascal is quoted in the comments as ideal, and that is also manually allocated).

In general if you teach a language that has fully automatic allocation, you often get lazy and ad-hoc programming behaviour of students. If your group is very small, this is not a problem, but with larger (20–30+) groups, the effort students put into it decreases, simply because the manual allocation encourages some self discipline and thinking before doing.

This is not always the case; As said small groups or also a very precise specification and proofing system can remedy this. However that kind of exact thinking is often harder for most categories of students than manual allocation for simple programs.

---

Something else if you are interested in education and selecting introductionary languages and courses:

I happen to have had two introductionary courses in my (too) long carrier as student, and was struck by the differences. One during my chemical engineering (Master) study (Pascal courses in the first year, some numerical programming in the second year 1992–1994), and one during my CS bachelor (as a quite experienced programmer meanwhile) this year (2002–2003)

The first was in Turbo Pascal, on the dos command line. The second Java (JBuilder and Visual Cafe ). Parallel to this we also got a basic (plain) C course for embedded use, using Visual C++ 6.0, but targeted towards command line usage.

While to me, the theoretic level of the C course was harder (creating and managing double linked lists vs. stuffing things in and out of a vector), the other students' (and me too) perception was that the Java course was much more difficult and time consuming.

I hadn't expected that, so I talked with the other students about this, and the difference was caused by several factors:

The primary factor was GUI<-> text. While most had to be learned to use the console (and redirecting etc), it was considered easier than even the very small GUI proportion of the Java demos (nr of controls per assignment 2-5, usually even pre-prepared by the teacher)
The larger amount of basic concepts to be learned (particularly OOP inheritance was a great hindrance)
the compactness of the C source made it easier, also the straightforwardness (the easy to follow sequence of things. Event driven is more complicated)
The IDE/RAD. VC++ was used as a GUI editor+ a knob to build. One needed to know the Java RAD much better to adequately make and debug the assignments

So in general, it was the larger amount of concepts and knowledge required to make initial, simple programs.

The Pascal case (Turbo Pascal) at the time went even better, but at that time all computer users still had a decent dos and cmdline knowledge. That's much harder nowadays. For teaching, the string handling of TP is a really big plus over C though IMHO, and Pascal is also much cleaner than C in a lot of ways.

Using Dev-Pascal instead could remedy this (by switching to a GUI editor, minimizing the cmdline work). I think this is easier than Delphi even, since the IDE is much simpler, and not geared towards making RAD generated GUI apps.

Hmm, enough ranting for a day :_)

Usenet Source description

From: Marco van de Voort 
Message-ID: <slrnbhv9re.1e9l.marcov@toad.stack.nl> 
Newsgroups: comp.theory.cell-automata,comp.lang.java.advocacy,comp.lang.scheme,comp.lang.misc 
Subject: Re: Cellular automata benchmarks: Java vs C++ vs Java vs C++ 
Date: Thu, 24 Jul 2003 09:31:27 +0000 (UTC)

Meinungen zum Thema dieser Seite

H. S. Lahman writes:

Responding to Gunnar G…

> I'm looking for ideas for a OO programing course with C++.
> I need some good examples of programs that one can write that are not to big
> (a few hundred up to a thousand lines) is alright, but still feels
> meaningful.

Assuming from the message title that you are going to be teaching the basic OO paradigm to novices, then I agree with O'Leary – C++ is a terrible place to start. In fact, I would argue that one needs to understand OOA/D first before going near any OOPL. But if you are going there, then Smalltalk is probably the best choice.

Usenet Source description

From: "H. S. Lahman" 
Message-ID: <Kf7Df.1590$0J3.367@trndny08> 
Newsgroups: comp.object 
Subject: Re: Teaching OO 
Date: Sun, 29 Jan 2006 17:50:34 GMT

Bjorn Borud writes:

Java books are usually about doing stuff. C++ books are mostly about not shooting yourself in the foot. that just about sums up how you use the two environments too.

Elliott Hughes :

As an aside, an interesting difference between "Effective Java" and "Effective C++" is that my reaction to the latter was to come up with a set of SOPs that mainly boil down to "don't use C++ feature x". Whereas "Effective Java" was more like "use idiom x when using Java feature y". An interesting consequence of which is that I'm much better able to articulate why I do things the way I do in Java than I am in C++.

(…)

Another interesting contrast with C++ is that, whenever you read a book on C++ you're likely to spend most of your time thinking about how the language could be improved, but reading books like this on Java, you're more likely to think about how the libraries could be improved.

http://elliotth.blogspot.com/2008/10/review-effective-java-2nd-edition.html

Usenet Source description

From: Bjorn Borud <borud-news@borud.no> 
Message-ID: <m3is1ti9kq.fsf@borud.not> 
Newsgroups: comp.lang.java.programmer 
Subject: Re: Why Generics? 
Date: 09 May 2005 01:25:57 +0200

H. S. Lahman writes:

C++ is generally regarded as the most technically deficient of the popular OOPLs. A major reason was the that performance and low-level machine control were primary design objective. That results in a lot of compromises. Given the design goal, it is not bad. However, the prices one pays are that a higher skill is required to use it properly and there are a lot more opportunities for foot-shooting.

Usenet Source description

From: "H. S. Lahman" <h.lahman@verizon.net> 
Message-ID: <bv6je.8995$_f7.1506@trndny01> 
Newsgroups: comp.object 
Subject: Re: Lahman, how ya doing? 
Date: Thu, 19 May 2005 20:17:11 GMT

Bertrand Meyer :

There are only two things wrong with C++, The initial concept and the implementation.

Linus Torvalds :

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

http://lwn.net/Articles/249460/

Steve Yegge

“One the one hand, I think nobody in their right mind would try to write a gigantic system in C++ now that Java has become an obviously far superior way to build large systems. You can argue that in C++ you really have to know what you're doing, or that you love the smell of freshly-brewn pointer arithmetic in the early morning, or whatever the hell you like about C++. I'm not arguing that you LIKE it — I know you do. I liked assembly language when I was using it daily. I'm just saying that the game has moved on, and if you're using C++ to build large systems because you like C++, it's like competing in the Indy 500 with your 1980 5.8-liter Pontiac Firebird. It gets you around, and it's fun to tinker with, which is good 'cause it breaks down all the time, but you're not going to win any world championships with it.”

http://steve.yegge.googlepages.com/practical-magic

Steve Yegge

“C++ is a vast playground, and makes you feel smart when you know all of it, so you're always tempted to use all of it. But that's really, really hard to do well, because it's such a crap language to begin with. In the end, you just make a mess, even if you're good.”

http://steve.yegge.googlepages.com/tour-de-babel

Jamie Zawinski

“It was decisions like not using C++ and not using threads that made us ship the product on time. ”

http://www.joelonsoftware.com/items/2009/09/23.html

Pascal J. Bourguignon

“C++ has always been a zombie, its only drive is the C ghost inside it :-)”

Usenet Source description

From: "Pascal J. Bourguignon" <pjb@informatimago.com> 
Message-ID: <7cfxdrp4pj.fsf@pbourguignon.anevia.com> 
Newsgroups: comp.lang.c++ 
Subject: Re: Should this forum become moderated? 
Date: Tue, 23 Jun 2009 13:30:48 +0200

Ron Garret writes:

The ad server, the machine that actually served up ads in response to search terms, ran multi-threaded code written in C++, which is more or less the industry standard nowadays for high-performance applications. C++ is byzantine, one of the most complex programming languages ever invented. I've been studying C++ off and on for ten years and I'm still far from being an expert. Its designers didn't really set out to make it that complicated, it just sort of accreted more and more cruft over the years until it turned into this hulking behemoth.

C++ has a lot of features, but one feature that it lacks that Lisp and Java have is automatic memory management. Lisp and Java (and most other modern programming languages) use a technique called garbage collection to automatically figure out when a piece of memory is no longer being used and put it back in the pool of available memory. In C++ you have to do this manually.

Memory management in multi-threaded applications is one of the biggest challenges C++ programmers face. It's a nightmare. All kinds of techniques and protocols have been developed to help make the task easier, but none of them work very well. At the very least they all require a certain discipline on the part of the programmer that is very difficult to maintain. And for complex pieces of code that are being worked on by more than one person it is very, very hard to get it right.

[Ron Garret now describes that a bug occurred, that has to do with multi-threading and memory management in C++.]

On top of that, this kind of bug is actually impossible to introduce except in a language with manual memory management like C++. In a language with automatic memory management like Java or Lisp the system automatically notices that the memory is still in use and prevent it from being reused until all threads were actually done with it.

By the time this bug was found and fixed (...) I was a mental wreck, and well on my way to becoming a physical wreck as well. My relationship with my wife was beginning to strain. My manager and I were barely on speaking terms. (...)

http://xooglers.blogspot.com/2005/11/racing-to-finish.html

Michael Kölling :

The problem of teaching object-oriented programming (…)

C++ fails to meet almost all requirements on our list. It is a hybrid language that does not support the concepts in a clean way, has a highly redundant set of constructs, an unsafe type system and a highly complex execution model. Some of the most important points in more detail:

Clean concepts – Whatever can be said in favour of C++, it is not that it represents any abstract concepts in a clean way. Two of the most influential design decisions in the development of C++ were to retain full backwards compatibility with C and to regard efficiency in time and space as a main goal. (Stroustrup stated that “time and space overheads above those for C are considered unacceptable for C++ ” [8].) Both those characteristics have the effect that the representation of many important language constructs is heavily influenced by low-level considerations that distinguish the concrete representation from the abstract concept. Often, subtle implementation details need to be understood to correctly use fundamental constructs.

Safety – One of the most serious criticisms of C++ is its lack of type safety. Almost all its higher level constructs can easily be corrupted. The explicit dynamic storage allocation in C++, in combination with the lack of garbage collection, also greatly increases the risk of errors. Often C and C++ programs that have been tested and used for some time have “memory leaks” and other bugs that are caused by improper storage handling.

High level – C++ includes numerous constructs for low-level manipulations. Bit operations and pointer arithmetic, for instance, are frequently used in typical C++ programs. The use of explicit storage management not only allows but forces the programmer to think at an unnecessarily low level.

Simple object/execution model – The object model supported by C++ is clearly the most complex of the languages included in this survey. This is caused in part by C++ ’s support for pointer and non-pointer (“automatic”) variables, as well as the semantics of some important constructs.

Readable syntax – The lack of readability is another negative point for C++. Its syntax is overly terse and has as one of its most obvious features its favouritism of symbols over keywords. As a result of this, C++ often overloads the same keyword for different purposes or uses unintuitive symbolic constructs (consider, for example, the syntax for the definition of an abstract function: virtual void f () = 0; ). By employing a syntax similar to variable assignment, the meaning of the construct is hidden and the declaration becomes unreadable to a non-C++ -programmer. There are numerous similar examples in the language.

No redundancy – The decision to keep C++ upwards compatible with C has led to the evolution of a large number of redundancies and surprising interactions of concepts, and greatly increases the complexity of the language. The list of problems mentioned here could easily be extended. Many other problems have been pointed out and discussed in much detail in the literature (e.g. [9-11]). Detailed discussion of all of them would exceed the space we want to devote to this language.

Overall, C++ is one of the worst candidates for our needs. (…)

[8] Ellis, M. A. and B. Stroustrup, The Annotated C++ Reference Manual, Addison-Wesley, Reading, MA, 1990.

[9] Joyner, I., "C++ ?? - A Critique of C++ and Programming Language Trends of the 1990s, 3rd edition ", Unisys - ACUS, Report , 1996.

[10] Pohl, I. and D. Edelson, "A to Z: C Language Shortcomings," Computer Languages, 13(2): 51-64, 1988.

[11] Sakkinen, M., "The darker side of C++ revisited," Structured Programming, 13(4): 155-177, 1992.

(…)

http://www.bluej.org/papers/1999-08-JOOP1-languages.pdf

http://www.idi.ntnu.no/emner/sif8005/Live%20programmering/Artikler%20didaktikk/the-problem-of-teaching.pdf

http://gernotvonmedard.de/scheme/1999-08-JOOP1-languages.pdf

http://www.mip.sdu.dk/sweat/publications/mik-thesis.pdf

Robin Rosenberg :

I had a nightmare once in which I a had convinced a friend how wonderful C++ is. A while later he came back., and he was mad.

http://groups.google.com/groups?selm=1fYEA-pz-21%40gated-at.bofh.it

Linus Torvalds :

Why don't we rewrite the Linux kernel in C++?

“In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:

the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.

any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.

you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is either

(a) looking for problems

(b) a C++ bigot that can't see what he is writing is really just C anyway

Feel free to make up (d).”

http://www.tux.org/lkml/#s15-3