Ein kritische Betrachtung von C++

[LiMuBei]

Bin gerade auf diese Website gestoßen: http://yosefk.com/c++fqa/

Ich programmiere ja eigentlich ganz gern in C++, aber was der Mann sagt hat mich auch schon des öfteren einiges an Nerven gekostet. Ich bin schon auch der Meinung dass C++ in vielen Bereichen schelcht designt ist. Grade der Mangel an anständigen IDEs belegt das recht gute denke ich.

Meine Ausflüge zu Python in letzter zeit haben dieses Bild noch etwas verstärkt. Vielleicht werde ich mich demnächst mal an C# ranwagen...

Wie sind eure Erfahrungen mit C++? Welche anderen Sprachen habt ihr ausprobiert und was fandet ihr besser/schlechter?

[Centurion]

Ich hab den Artikel jetzt nicht gelesen, aber für mich ist C++ als Sprache im Prinzip überholt. Ich sehe an C++ nichts, was man nicht in anderen Sprachen wie Python syntaktisch kompakter, eleganter, verständlicher und intuitiver lösen könnte. C++ ist ganz einfach weniger stark abstrahiert als modernere Sprachen, was in meinen Augen als Entwickler grundsätzlich ein (Produktivitäts-)Nachteil ist. Die andere Seite ist jedoch, dass der geringere Abstraktionsgrad für einen Compiler-Entwickler ein Vorteil ist. Es gibt nach wie vor für keine verbreitete Sprache einen Compiler, der so stark optimieren kann, wie die verbreiteten C/C++ Compiler. Das ist in meinen Augen der einzige Grund, warum C++ immer noch so stark verwendet wird: Wenn man maximal optimierten Maschinencode rausbekommen will, kommt man halt fast nicht dran vorbei.

Das soll jetzt nicht heißen, dass ich nichts mehr von C++ wissen will. Ich bin sehr froh, C und C++ früh gelernt zu haben, weil der geringe Abstraktionsgrad ein sehr gutes Verständnis vom Programmieren erzwingt. Wenn man mit Java anfängt und mit noch "bequemeren" Sprachen weitermacht, lernt man z.B. nie wie Speicherverwaltung funktioniert. Aus demselben Grund fand ich auch die Assembler-Aufgaben in der Uni sehr lehrreich. Aber ich würde nie auf die Idee kommen, produktiven Assembler-Code schreiben zu wollen. Und produktiven C/C++-Code zu entwickeln, will ich in Zukunft auch möglichst vermeiden.

Seit ich angefangen habe, zu arbeiten, habe ich nur in ABAP Objects entwickelt. Das ist halt etwas ganz anderes. Erstens ist der Abstraktionsgrad höher (Speicherverwaltung mit Garbage-Collection, OO mit Interfaces usw., objekt-orientiertes Eventing) als bei C++. Tatsächlich ist der ABAP-Interpreter selber in C++ geschrieben. Zweitens ist es eine relativ domänenspezifische Sprache: Hochoptimiert für transaktionale, datenintensive, betriebswirtschaftliche Anwendungen. Drittens ist es auch eine sehr alte Sprache, die mal als Makro-Sammlung für IBM-Mainframe-Assembler angefangen hat (vor ca. 30 Jahren). Aus Kompatibilitätsgründen gibt es auch heute noch sehr viele der alten Sprachelemente, die aus heutiger Sicht unmodern und gefährlich sind. Ist ein bisschen als hätte man C, C++, Java und Python in einem.

[Behemoth]

Habe den Text mal überflogen. Abgesehen von ein paar Fehlern ("operators can't return references in C++") ergeben sich die meisten "defective" Sachen schlicht aus der Tatsache, dass C/C++ Programme eben NICHT in einer kontrollierten Umgebung laufen. Reflektion? Überwachung von Array-Boundaries? Wer soll denn das machen, wenn zwischen Programm und Hardware keine Schicht mehr ist? Speicherverwaltung? Hrhrh. Erinnert mich an einen alten Witz:

Prolog-Programmer: Memory-Management is too important to leave it to the programmer
C-Programmer: Memory-Management is too important to leave it to the system

Der große Nachteil von C++ ist halt auch der große Vorteil: man hängt direkt an der Hardware. Wenn es um Performance geht, kommt man nicht daran vorbei. Oder noch ein Punkt, den viele vergessen: in welcher Sprache sind denn die Umgebungen geschrieben, in denen Programme anderer Sprachen laufen? Am Ende ist es immer etwas hardwarenahes, ob es jetzt C, C++, objective C oder Assembler heisst.

Abgesehen von den inherenten Problemen/Vorteilen von C++, kann man gerne sagen, Programmieren in C++ ist wie das Arbeiten mit anderen Expertensystemen: man kann damit alles machen, was man will, und genau so, wie man es will. Allerdings muss man genau wissen, was man will.

C++ ist jetzt nicht die Lösung aller Probleme, aber in dem Bereich, für den es ja eigentlich gedacht ist und immer noch verwendet wird, führt im Moment kein Weg daran vorbei. Vor Jahren habe ich mal von D++ gelesen, das ein "besseres C++" mit erweiterten Funktionen sein soll, aber danach irgendwie nie wieder etwas davon gehört. Bei der C++ Programmierung liegen die Features im Compiler - was die Sprache kann ist eigentlich nur davon abhängig. Wenn einem also bestimmte Features fehlen, kann man sie eventuell mit einem anderen Compiler einfach bekommen.

C++ hat seine Daseinsberechtigung, aber für die meisten Programmieraufgaben (und die meisten Programmierer) ist es nicht das Mittel der Wahl, da stimme ich vollkommen mit überein. Dummerweise ist ja immer noch die Ansicht, jeder Programmierer dürfte nur eine einzige Programmiersprachen beherrschen, weit verbreitet.

If the only tool you have is a hammer, everything starts looking like a nail.

[Behemoth]

Zum Thema andere Sprachen: ich bin in letzter Zeit recht überascht davon, wie gut sich viele der Feautures anderer Sprachen misbrauchen lassen, wenn die Leute, die darin programmieren etwas, aber nicht die volle Ahnung haben. Am schlimmsten ist es dabei mit den Scriptsprachen, in meinem Fall gerade Flash Actionscript 3 und PHP5, aber das neue Java ist auch gut dabei.

Bei den Scriptsprachen ist einer der schlimmste Missbrauchfall einfach, dass man (Reflektion und managed Environment sei Dank!) Attribute und Methoden von Klassen und Objekte beliebig verändern kann, idealerweise zur Laufzeit - yay, viel Spaß beim Debuggen!

AS3 bietet sehr komfortable setter und getter Methoden - sehr elegant, eigentlich. Dummerweise werden die von allen dafür misbraucht, komplizierte Funktionsaufrufe hinter Anweisungen wie cube.x = 32 zu verstecken. Wer erwartet bei der Anweisung, dass der Würfel neu plaziert und alle Objekte neu gezeichnet werden?

Oder Java bietet mit seinen Annotations Ansatzpunkte, um zB. persistente Objekte sehr elegant zu realisieren - geschickt eingesetzt kann man damit aber auch alle objektorientierten Verhalten in Java einfach ignorieren.

Es kommt halt einfach drauf an, was man eigentlich programmieren will.

[Centurion]

Ich stimme Jan voll zu. Für mich ist die ideale Situation für einen Entwickler C++ vollständig zu verstehen und darin programmieren zu können, aber tatsächlich eine "höhere" Sprache zu verwenden. Da hat man üblicherweise ein gutes Verständnis davon, was die zusätzlichen Features der höheren Sprache tatsächlich bedeuten und einen guten Kompromiss aus Produktivität und hochwertigem Code.

[LiMuBei]

Für mich ist C++ auch einfach etwas was einem sehr viel Freiheiten gibt, aber dadurch halt auch eine ziemliche Verantwortung auferlegt. Ich hab auch mal so durchüberlegt was denn für den Herren dieser Website eine Sprache wäre die seine Ansprüche erfüllt. Das könnte ja höchstens sowas wie Java oder C# sein, aber wenn ich z.B. überlege wie ich damit unsere Roboterhardware hier ansprechen sollte...hmm...da müsste ich wohl sowas wie nen C++-Wrapper schreiben. Managed Umgebungen sind ja wunderbar bequem zum Programmieren, aber eben auch recht beschränkt. In den Punkten kann ich Jan nur voll zustimmen.

Nichts desto trotz bleibt bei C++ oft der Beigeschmack dass die Produktivität - gerade bei simplen Dingen wie Text parsen - doch recht beachtlich leidet. Es ist halt einfach wenig von sich aus drin und man muss sich die Arbeit machen sich brauchbare Bibliotheken zu suchen. Diese dann selber zu bauen und korrekt in das eigene Projekt einzubinden ist dann nochmal ne ganz andere Geschichte...

Ich hab ja vor einiger Zeit auch mal mit der C++-Variante von .net programmiert. Das ging schon stark in die Richtung die ich gut fände. Allerdings ist da halt immer das Problem dass wenn man was zwischen managed und unmanaged hin- und herschieben muss das ein ganz schöner Heckmeck ist. Ansonsten bietet das aber schon sehr viel "out of the box". Auch die Einbindung von weiteren Bibliotheken aus dem .net-Set ist sehr angenehm gelöst. In Linux ist sowas über die Paketverwaltung ja eigentlich auch schon recht gut gelöst, ich finde wenn in der Richtung mal was halbwegs einheitliches entwickelt werden würde, dann wäre ich mit C++ schon recht glücklich.

[Magic]

Hm, schreibt ihr von der Arbeit aus? ^^ (Bei Alex ist's klar, kein Thema. )

Ich habe eigentlich kaum was zu ergänzen. Inzwischen durfte ich ja einige Programmiersprachen lernen. C++ halte ich nach wie vor für die beste, um zu verstehen, wie Algorithmen auf Code-Ebene arbeiten. Genauso wie Dominik schreibt, Assembler lernen ist top, um zu verstehen, was für Befehle der Computer eigentlich entgegen nimmt. Praktisch gesehen taugen C-verwandte Sprachen wirklich nur zur Geschwindigkeitsoptimierung ... und als Hobby. Programmieren ist ja eine Sache, aber Wartung! Fremden Code debuggen, wenn darin mit Zeigern jongliert wird - spaßige Sache. Bezüglich konkreter höherer Software-Entwicklungssprachen kann ich leider gar nicht mitreden. Bot sich irgendwie nicht die Gelegenheit für mich, würde ich aber auch empfehlen.

Edit: Ok, ich habe etwas auf der Seite geschmöckert. Den meisten Problemen bin ich vermutlich gar nie begegnet. Klar, der Autor treibt es absichtlich auf die Spitze. Oftmals schaufelt man sich aber wohl das eigene Grab, nur C++ verhindert es halt nicht. Dennoch, C++ kann eben besonders gut die Untiefen der Programmierung aufzeigen.