C++ macht wirklich Spaß

 (learncodethehardway.com)
1 Punkte von GN⁺ 2024-12-25 | 1 Kommentare | Auf WhatsApp teilen
  • C++ hat sich seit C++11 als Sprache und Ökosystem stark verändert und ist zu einer Sprache geworden, die beim Selberbauen und Experimentieren den Spaß am Programmieren wiederbelebt
  • Eine Zeit lang blieb C++ vielen Entwicklern wegen eines Übermaßes an Template-Metaprogrammierung sowie einer stark auf Standards und Patterns fixierten Kultur als ermüdende Sprache in Erinnerung
  • Änderungen wie auto, nullptr, range-for, Lambdas, <chrono>, Smart Pointer und <thread> haben den Coding-Stil in C++ deutlich verändert
  • Modernes C++ bietet heute viele Optionen – von Dateisystemen, Paketverwaltung, GUI/TUI, Grafik, Mathematik und AI bis hin zum Zugriff auf OS-APIs –, sodass es einfacher ist, selbst zu bauen, was man möchte
  • Nachteile wie Compiler-Fehler, Build-Tools, Standardkonformität, historische Komplexität und RAII bleiben bestehen, doch die kreativen Möglichkeiten überwiegen diese Unannehmlichkeiten

Warum C++ wieder Spaß macht

  • Beim Bau eines kleinen Roguelike-Spiels wurde der Dijkstra-Algorithmus für die Kartengenerierung genutzt, um Tunnel zu implementieren, die Räume verbinden; dabei stand C++ dem Experimentieren nicht wesentlich im Weg
  • Auch das Experiment, die Benutzeroberfläche von FTXUI direkt in ein Render-Fenster von SFML zu zeichnen, war möglich; dabei ging es auch darum, die Unicode-Verarbeitung in C++ zu lernen
  • Diese Arbeiten waren nicht einfach, aber tatsächlich möglich – und das Gefühl „Diese Idee hat wirklich funktioniert“ macht den Reiz von C++ aus
  • Der Grund, mit dem Programmieren anzufangen, war nicht, Milliardären noch mehr Geld zu verdienen, mit Rendering-Engines zu kämpfen oder die oberen Ebenen eines Open-Source-Projekts zufriedenzustellen, sondern die Freude daran, Ideen umzusetzen

Die Ermüdung der Template-Metaprogrammierungs-Ära

  • Von den späten 1990er- bis in die frühen 2000er-Jahre herrschte in C++ eine starke Tendenz, Template-Metaprogrammierung auf alles anzuwenden; diese Phase gilt als Wendepunkt, der C++ weniger spaßig machte
  • Es gab Diskussionen nach dem Muster, dass das Addieren zweier Zahlen per Template schneller sei als direktes Addieren; als Beispiel wird jedoch angeführt, dass der tatsächliche Assembly-Output identisch war
  • Auch die Wahrnehmung, dass das C++-Standardkomitee wenig Interesse daran hatte, Programmierern eine gute Usability zu bieten, verstärkte die negativen Erfahrungen
  • C++ blieb damals als Sprache in Erinnerung, die viele spitze Klammern <> und komplexe Syntax hatte, aber wenig Gegenwert bot
  • Auch Java wirkte anfangs wegen Garbage Collector und Entwicklerfreundlichkeit attraktiv, führte später aber durch Boilerplate und ein Übermaß an Design Patterns zu einer ähnlichen Ermüdung

Wie C++11 das Gefühl der Sprache verändert hat

  • Die in C++11 hinzugefügten Funktionen gelten als Veränderungen, die den Eindruck von C++ stark gewandelt haben
  • Zu den wichtigsten Funktionen gehören:
    • auto: ein Schlüsselwort für automatische Typerkennung, das die Last reduziert, denselben Typnamen wiederholt aufzuschreiben
    • nullptr: eine Darstellung für Nullzeiger, die die Probleme von Cs NULL behebt
    • range-for: eine Schleife, die zusammen mit auto die Iteration über Container vereinfacht
    • lambda expressions: Lambdas, die API-Design und Usability erheblich verändern können
    • <chrono>: eine typsichere Zeitbibliothek, die Ausdrücke wie 100ms ermöglicht
    • <regex>: Regex-Funktionalität in der Standardbibliothek
    • unique_ptr, shared_ptr: Smart Pointer für Ownership und Reference Counting
    • <thread>: Funktionen, die Multithreading in das grundlegende Sprachökosystem integrieren
  • C++11 veränderte die Philosophie und den Stil der Sprache, ohne die bisherigen Ansätze zu verwerfen; in dieser Hinsicht wird es ähnlich wahrgenommen wie ES6 bei JavaScript

Optionen im modernen C++-Ökosystem

  • Modernes C++ besitzt viele der Funktionen, die man von anderen Sprachen erwartet
  • Beispiele für genannte Tools und Bibliotheken sind:
  • Die Qualität des Ökosystems variiert je nach Bereich, wird insgesamt aber höher eingeschätzt als das, was man aus JavaScript und Python erlebt hat
  • Besonders FTXUI und die STL werden als Beispiele für gutes Design und gute Usability genannt

Breite Umsetzungsmöglichkeiten schaffen „Spaß“

  • C++ macht nicht nur deshalb Spaß, weil moderne Funktionen hinzugekommen sind, sondern wegen der Umsetzungsmöglichkeiten, mit denen sich nahezu alles bauen lässt
  • Desktop-Apps lassen sich mit fenster, SFML oder Qt bauen – oder indem man direkt mit OS-APIs arbeitet
  • Bei Sound reicht die Spanne von schnellen Optionen wie SFML bis zu kommerziellen Tools wie Wwise
  • Für 3D-Grafik gibt es viele Optionen wie OpenGL, Vulkan, Direct3D und Ogre3D
  • Im Bereich Mathematik gibt es Bibliotheken wie BLAS, Eigen und GMTL
  • Selbst wenn eine benötigte Bibliothek fehlt, kann man direkt über das C- oder C++-ABI und die Betriebssystem-APIs darauf zugreifen und selbst etwas bauen; dieser Prozess des direkten Selbermachens ist Teil des Spaßes

Kreative Freiheit einer Sprache abseits des Hypes

  • C++ hat eine hohe Sprach- und Ökosystemqualität, ist derzeit aber keine Trendsprache; dadurch erhält es weniger Aufmerksamkeit von Gruppen, die Sprachen kaputtmachen, so die Einschätzung
  • Die C++-Community wird als Umfeld beschrieben, das sich kaum einmischt, egal was man baut
    • Projekte wie Matrix-Bibliotheken, GUI-Bibliotheken, Game Engines oder seltsame Spiele lassen sich frei ausprobieren
  • Kreative Arbeit braucht sowohl eine Phase, in der Ideen zunächst nach außen gebracht werden, als auch eine spätere Phase, in der man nüchtern kritisiert und die Qualität erhöht
  • Bei anderen Sprachen wird Organisation, Leadership und Community-Druck zugeschrieben, Experimente in der Zwischenphase kreativer Arbeit zu behindern
  • Die breiten Möglichkeiten von C++ und eine vergleichsweise geringe Kultur des Beschämens können eine kreative Erfahrung ermöglichen

Die Stärken von cppreference.com

  • cppreference.com wird als eine der besten Dokumentationen für Programmiersprachen bewertet, die der Autor genutzt hat
  • Zu den Stärken gehören:
    • Alle Schlüsselwörter und Bibliotheken sind als Referenzdokumentation aufbereitet
    • Die meisten Einträge enthalten tatsächlich lauffähige Beispiele
    • Bei jeder Funktion wird angegeben, mit welcher C++-Standardversion sie eingeführt wurde
    • Es gibt Verweise auf Standarddokumente und relevante Referenzen
    • Ein DuckDuckGo-basiertes Suchfeld erleichtert das Finden, selbst bei Tippfehlern oder wenn man den exakten Begriff nicht kennt
    • Auch wichtige Konzepte wie Copy elision werden mit Beispielen erklärt
  • Ein Mangel ist, dass Anleitungen zur Installation von Compilern auf verschiedenen Plattformen fehlen
  • Da die Zahl der C++-Compiler und Plattformen nicht sehr groß ist, gäbe es auch Raum für einen Einstiegsguide

Die weiterhin bestehenden Probleme von C++

  • Das bedeutet nicht, dass C++ eine perfekte Sprache wäre; wie andere Sprachen hat sie viele unbequeme Seiten
  • Unter Windows ist es schwierig, Compiler und Entwicklungstools über einen nicht von Microsoft vorgegebenen Installationspfad einzurichten; dafür wurde ein eigener PowerShell-Installationsskript erstellt
  • Die derzeit wichtigsten Unannehmlichkeiten sind:
    • Mehr als 95 % der Compiler-Fehlermeldungen werden als die schlechtesten der Branche bewertet
    • Build-Tools sind schwer zu verwenden; auch Meson verursachte Probleme, weil es Anweisungen zu installierten Paketen ignorierte und eine defekte Systembibliothek verwendete
    • Es gibt zu wenig Anreize, Compiler-Hersteller zur Einhaltung des Standards zu bringen
    • C++ ist wegen seiner Geschichte sehr komplex; alter Heap-Allokations- und Raw-Pointer-Stil, Template-Metaprogrammierungsstil, der seit C++11 verbreitete stack-zentrierte Stil und ein neuerer struct-zentrierter Stil existieren nebeneinander
    • RAII stört in realistischen Konfigurationssituationen oft; es wird ein Mittelweg zwischen Initialisierungskonstruktoren nach Art anderer Sprachen und dem heutigen RAII als nötig angesehen
  • Trotz dieser Nachteile ist die Unbequemlichkeit von C++ nicht so groß, dass sie den Spaß zerstört; C++ entspricht nicht mehr dem alten Eindruck einer Sprache, die vor allem aus spitzen Klammern und Pointern besteht
  • GUI-Layout-Code mit FTXUI ist ein Beispiel für moderne Syntax, die so wirkt, als stamme sie aus einer anderen Sprache, wenn man nicht weiß, dass es C++ ist

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-12-25
Meinungen auf Hacker News

  • Ich bin zwar eher ein C++-Hasser, aber das liegt daran, dass ich es nicht mag, C++ in geschäftskritischem Code zu verwenden, der zuverlässig sein muss, und das zusammen mit Kollegen, denen man nicht vollständig vertrauen kann.
    Bei persönlichen Projekten gehörte es zu den befriedigendsten Coding-Umgebungen, die ich je ausprobiert habe, und die Möglichkeit, die Ausführung extrem fein zu steuern, ist wirklich aufregend.
    Ich habe C++ vor etwa zehn Jahren verlassen und habe nicht vor zurückzukehren, aber für meine heutigen Projekte ist langfristige Zuverlässigkeit das Wichtigste, daher passt Rust + CI/CD genau.
    Trotzdem vermisse ich den Kick, ein Programm so zu entwerfen und zu implementieren, dass es exakt so läuft, wie ich es beabsichtigt habe, und zu wissen, dass das meiner Expertise und meinem Verständnis zu verdanken ist.
    Ob ich möchte, dass Leute, mit denen ich zusammenarbeite, von so einer Motivation getrieben sind? Auf keinen Fall. Aber persönlich ist es ein unvergesslicher Spaß.
    Build-Systeme und Paketverwaltung sind ein Albtraum, der Präprozessor wirkt wie ein sadistischer Witz, die Syntax ist schrecklich, und zur Laufzeit gibt es viel zu viel Altlasten-Kram, für den man jahrelange Erfahrung braucht, um sich nicht mit einem Maschinengewehr in den Fuß zu schießen.
    Aber in gewisser Weise steigert all dieses Leid die Freude noch, wenn man schließlich eine ausführbare Datei ausliefert, die in Cleverness und blutige Tränen gehüllt ist.

    • Das ist eine der treffendsten Beschreibungen von C++, die ich gelesen habe.
      Ich habe einige Jahre beruflich C/C++ geschrieben und möchte nicht zurück.
      Ich habe viel zu viel Zeit damit verbracht, fremden Code zu debuggen, unklare Integrationsprobleme zu haben und Build-System-Spaghetti am Laufen zu halten.
    • Arbeit sollte genauso spaßig sein wie persönliche Projekte.
      Ich habe das Gefühl, dass die Tech-Branche diesen Gedanken in den letzten zehn Jahren verloren hat, und mache dafür große Tech-Konzerne verantwortlich, die die besten Leute in Erwachsenen-Gefängnisse mit gutem Essen und weichen Stühlen stecken.
      Auch Startups sind weniger spaßig geworden, und weil die VC-Branche ein enges Denkfenster fördert, gibt es zu viele Copycat-Startups und Trends, die alle dasselbe bauen.
      Der Grund, warum ich für jedes neue Projekt C++ verwende, ist die Gewissheit, dass ich Dinge selbst bauen kann, wenn ich sie bauen muss.
      Frameworks verhalten sich oft nicht so, wie ich es möchte, besonders wenn es um den Kern eines Projekts geht, daher möchte ich sie nicht dauerhaft verwenden.
      Wenn man es selbst bauen kann, baut man es selbst; wenn nicht, nimmt man ein Framework.
      Wenn man es selbst bauen kann, ist C++ ein großartiges Werkzeug, das alles kann und einem in den wichtigen Aspekten nicht im Weg steht.
      Sprachen wie Rust können sich beschweren, dass ich gefährliche Dinge tue, aber in C++ kann ich das Modell in meinem Kopf direkt ausdrücken.
      Manchmal denkt man in Pointern, und Pointer sind wirklich gute Werkzeuge.
      Holen wir uns den Spaß zurück, nicht nur im Privatleben, sondern auch bei der Arbeit.

  • Dieser Artikel wirkt etwas wirr.
    Er spricht viele Punkte an, aber es ist schwer herauszulesen, warum daraus die Schlussfolgerung folgen soll, dass C++ mehr oder weniger Spaß macht.
    Es ist auch verwirrend, modernes C++ als von extrem hoher Qualität zu bezeichnen und gleichzeitig von umfangreichen Legacy-Problemen und schrecklichen Tools zu sprechen.
    Zu sagen, unique_ptr sei großartig, RAII aber wirklich furchtbar, und zu behaupten, Metaprogrammierung sei früher überall gewesen, heute aber nicht mehr, wirkt ebenfalls seltsam.
    Wenn man sich concepts ansieht, stimmt das nicht; auch die Aussage, C++ habe die besten Grafikbibliotheken, oder dass die Python-Installation schwieriger sei als C++, wirkt eher wie eine Obsession des Autors ohne großen Bezug zur Argumentation.
    Letztlich scheint der Autor C++ wegen einer komplexen Mischung persönlicher Faktoren spaßig zu finden, und das ist an sich in Ordnung.
    Wegen der Performance und seines technischen Charakters hatte ich mit C++ ebenfalls einige meiner spaßigsten Programmiererfahrungen, aber in der praktischen Softwareentwicklung ist C++ aus vielen bekannten Gründen nicht besonders gut.
    C++ ist eine zutiefst widersprüchliche Sprache, gezeichnet von Jahrzehnten an Legacy und Politik, und die Realität von C++ zu ignorieren, ist der größte Fehler in Diskussionen über C++.
    Meine heutige Haltung zu C++ ist eher Erschöpfung, und ich habe keine Lust mehr, über die Hürden zu springen, die C++ mir über die Jahre in den Weg gelegt hat.
    Man muss ein schon viel zu lange totes Pferd nicht weiter prügeln; C++ kann einfach C++ bleiben.

    • Ich finde, dieser Satz fasst den Kern des Artikels gut zusammen.
      Aus meiner Sicht ist der Text weniger wirr, sondern eher so, dass der Autor Freude daran hat und diese Freude so gut wie möglich teilen möchte.
      Es ist weniger ein sauberer Meinungsartikel, der aktiv überzeugen will, als eher: „Wenn du das auch ohne Überzeugungsarbeit nachvollziehen kannst, könnte es dir ebenfalls Spaß machen.“
      Wenn man aus der Perspektive kommt, in kommerzieller Arbeit von der Realität verprügelt und müde geworden zu sein, ist es völlig verständlich, dass einem das unsinnig vorkommt.
      Ich habe ausgerechnet mit JavaScript heutzutage enorm viel Spaß; wenn ich einen ähnlichen Text schreiben würde, würde er sich für jemanden, der von den letzten zehn Jahren kommerziellem JavaScript erschöpft ist, wahrscheinlich genauso schlecht lesen.
      Trotzdem freut es mich, dass der Autor Spaß daran hat und sich entschieden hat, diese Freude zu teilen.

  • Ich habe drei Tage damit verbracht, eine Third-Party-Abhängigkeit in einem C++-Projekt unter Linux/Windows/macOS per Static Linking zum Laufen zu bringen.
    Das Paket war weder in conan noch in vcpkg, sondern nur ein GitHub-Repository mit einer seltsamen Kombination aus Makefile und cmake.
    Ich bin alles andere als ein cmake/cpp-Experte, aber in den meisten modernen Sprachen wäre das mit etwas wie pip install, cargo add, npm install oder go get kein Problem.
    Selbst wenn man ein Buch über die Details der C++-Semantik von vorne bis hinten liest, bleibt die Arbeit an echten Projekten schmerzhaft.

    • Auch die Dependency- und Build-Toolchain von JavaScript ist so undurchschaubar wie das schlimmste Makefile.
      Es ist erstaunlich, dass wir am Ende bei so etwas wie autotools für JavaScript gelandet sind.
    • Mich würde interessieren, was daran konkret schwierig war.
      Fremden Code statisch zu bauen oder so anzupassen, dass er auf anderen Plattformen baut, ist manchmal knifflig, aber das eigentliche Linken besteht normalerweise aus Include-Verzeichnissen, Library-Pfaden und der Angabe der Libraries.
    • Andersherum betrachtet frage ich mich, was besser wäre, wenn man diese Third-Party-Abhängigkeit in einer anderen „modernen“ Sprache verwenden wollte.
      Wenn niemand ein vcpkg-/conan-Paket dafür erstellt hat, ist sie wahrscheinlich auch nicht in pip/cargo/npm vorhanden.
      Wenn es in C++ schwierig war, könnte es in anderen Sprachen noch deutlich schwieriger sein.
      Allerdings zeigt sich auch hier, dass ein Teil der historischen C++-Realität, insbesondere die Build-Geschichte, in einem sehr schlechten Zustand ist.
      Sobald es nur in vcpkg enthalten ist, ist der Installationsaufwand genau vergleichbar mit anderen Ökosystemen.

  • Ich arbeite regelmäßig mal mit C++ statt mit C, und jedes Mal läuft es nach einem ähnlichen Muster ab
    Ich lerne eine neue C++-Technik kennen, schreibe Code, weil es sich anfühlt, als würde dadurch etwas besser, bekomme Compilerfehler und verbringe dann den Rest des Tages damit zu lernen, warum ich das, was ich will, nicht tun kann
    Meist hänge ich bei C++14 fest, und einige Probleme wurden in späteren Versionen behoben, aber trotzdem
    Ich würde C++ wirklich gern mögen; theoretisch gibt es einem ein mächtigeres C, das die Produktivität steigert, aber am Ende ist die kognitive Last so groß, dass ich meist einfach „C mit Klassen“ schreibe und weitermache

    • Es gibt einen Punkt, an dem Lernen Spaß macht, und der Autor des Originals scheint noch dort zu sein
      2003 habe ich viel Echtzeit-C++ geschrieben und es gehasst, aber letztes Jahr habe ich den Großteil meines Codes in C++ geschrieben und es endlich zu mögen gelernt
      Lambdas und auto waren der Wendepunkt, durch den ich C++ nicht mehr gehasst habe
      Templates habe ich auch ein wenig verwendet, aber hauptsächlich, um nicht für jede Variante derselben Funktion tonnenweise Branches schreiben zu müssen
      Dank Lambdas kann ich Code so schreiben, wie ich es ursprünglich von Lisp-nahen Lehrern im Stil von SICP gelernt habe
      Mit unique_ptr fand ich auch Allokationen nicht mehr unangenehm
    • Ich habe viel schlechten Code gesehen, der von Leuten geschrieben wurde, die gerade irgendein Feature gelernt hatten und es unbedingt einsetzen wollten
      Stattdessen sollte man zuerst überlegen, wie man den Code verwenden will, und dann ein Feature einsetzen, wenn es das Problem löst
      Problem → Lösung, nicht umgekehrt
      C++-Templates sind zum Beispiel im Allgemeinen furchtbar, aber Compile-Time-Duck-Typing oder das automatische Hinzufügen von Padding auf Basis von sizeof() können manchmal sehr nützlich sein
    • Meine C++-Erfahrung war exakt so
      Anfangs war ich C#-Programmierer und lernte wegen eines Embedded-Projekts C, und der Ablauf war genau derselbe
      C++ hat viele coole Features, die mächtig wirken, wenn sie exakt zur Anwendung passen
      Aber jedes Mal, wenn ich ein neues Feature ausprobierte, war das, was ich tun wollte, immer genau der Randfall, der in dieser Situation nicht funktionierte; nach Stunden oder Tagen gab ich auf und schrieb es einfach in C
    • C++ funktioniert, wie die meisten Technologien, besser, wenn man den Aufwand investiert, es richtig zu lernen
      Natürlich gibt es Sprachen wie Python oder Ruby, die von dieser Tendenz etwas abweichen
    • ChatGPT oder Copilot helfen bei solchen Dingen sehr
      Meist kopiere ich den Fehlertext hinein und lasse ihn entschlüsseln

  • C++ macht wirklich Spaß, und die Beschwerden der Leute hängen meiner Ansicht nach stark vom Kontext ab
    Viele C++-Entwickler hassen die Sprache, aber oft ist die Richtung dieses Hasses eigentlich falsch
    In Wirklichkeit haben sie es häufig mit Legacy-Produkten zu tun, die von Leuten gebaut wurden, die Software nicht besonders gut beherrschten
    Mir ist etwas Ähnliches mit Rust passiert: Ich wurde in ein bestehendes Rust-Projekt eines Unternehmens gesteckt, und in der alten Codebasis gab es viele miteinander kollidierende Konventionen
    Es gab Fehlertypen, die sich schlecht komponieren ließen, schlechte Klassenabstraktionen, unnötige unsafe-Blöcke und anderes; es war eines der quälendsten Projekte, an denen ich je gearbeitet habe
    Es ist leicht, Rust die Schuld zu geben, aber eigentlich war es einfach schlechte Softwareentwicklung
    C++ hat definitiv Fehler, aber ein großer Teil des Schmerzes, den Leute erleben, kommt daher, dass sie es mit schlechtem Code zu tun haben, der in jeder Sprache ein Chaos wäre

    • In fast jeder anderen Sprache außer C lädt man nicht jedes Mal zu beliebiger Speicherbeschädigung ein, wenn man v[x]=y schreibt
      Bei C++ ist std::optional: Wenn v leer ist und man *v aufruft, ist das undefiniertes Verhalten
      Der Kern von optional ist, einen Wert zu enthalten, der leer sein kann; schwer zu verstehen, warum man ausgerechnet bei der häufigsten Operation auf ein leeres optional undefiniertes Verhalten einbaut
      Aus Sicht von jemandem, der viel C++ verwendet hat, besteht das Problem darin, dass jeder Programmierer im Projekt zu 100 % der Zeit zu 100 % perfekt sein muss
      Man kann Speicherprüfer und den STL-Debugmodus laufen lassen, aber wenn man das nicht auch im Release tut, muss man hoffen, dass die Testsuite all die seltsamen Dinge abdeckt, die ein dummer oder böswilliger Nutzer tun könnte
      In einer Zeit, in der Software so wichtig geworden ist und Rust nahe an die Performance von C++ heranzukommen scheint, frage ich mich, ob es sich lohnt, eine Sprache zu verwenden, bei der viele grundlegende Funktionen sehr schwer sicher zu benutzen sind
      Es wird sogar immer schlimmer: Der Aufruf einer leeren std::function warf noch ein assert, aber das neue std::copyable_function macht daraus undefiniertes Verhalten
    • Dem kann ich schwer zustimmen
      Das Typsystem ist nervig, und dafür bekommt man nicht einmal echte Speichersicherheit
      Das Most Vexing Parse ist wirklich ärgerlich, und Merkwürdigkeiten, die von C geerbt wurden, wie Pointer Decay, sind ebenfalls noch da
      Darüber legt man dann neue Lösungen wie std::array, ohne die alten Wege abschaffen zu können
      Problematisch ist auch, dass man sich weiterhin auf den Präprozessor verlässt, um ein echtes Modulsystem zum Importieren nachzuahmen, was wiederum Umwege wie die Organisation von Klassencode oder das pimpl-Idiom nach sich zieht
      Im Kern sind die Mängel zu groß und zu zahlreich, als dass ich darin noch Schönheit finden könnte
    • Das stimmt, aber je komplexer eine Sprache ist, desto viel leichter lässt sich ein unverständliches Chaos erzeugen
      Ein Projekt in einer einfachen Blub-Sprache lässt sich dagegen unabhängig vom Zustand der Codebasis meist recht leicht entziffern
    • Die alte, aber ziemlich witzige C++ FQA ist einen Blick wert: https://yosefk.com/c++fqa/

  • Es freut mich, wenn jemand an C++ Spaß hat, aber ich persönlich bin nach über 20 Jahren damit an dem Punkt, an dem C++ für mich endgültig erledigt ist
    Es ist einfach ein Chaos
    Wenn ich wirklich Low-Level-Kontrolle brauche, nehme ich trotz seiner Macken C; sonst machen mich Rust, Python usw. deutlich glücklicher

    • Zustimmung
      Trotzdem wird C++ bleiben
      Es gibt einfach zu viel Code, der in dieser Sprache geschrieben ist; sie sicher zu beherrschen ist definitiv eine gute Fähigkeit, und es gibt sehr gut bezahlte Jobs dafür
      Für mich steht die Sprache zu sehr im Weg und fühlt sich übermäßig komplex an
      Ich kenne das Narrativ, dass „modernes C++“ großartig sei, man die alten Versionen nicht lernen müsse und jede neue Version einfacher werde
      Das Problem ist, dass die Codebases, an denen man tatsächlich arbeitet, kein modernes C++ sind
      Sie nutzen alle Features, die es je gab, und sind schwierig und voller Fallstricke
      Wer jahrelang nur in eigenen Projekten C++ gemacht hat, kann sich eine gewisse Expertise aufbauen und gegen die Komplexität immun werden, aber eine wirklich gute Sprache ist es nicht
    • Einer der Faktoren, die C++ im Lauf der Zeit erträglicher gemacht haben, ist, dass es leichter geworden ist, große Teile ganz natürlich durch Implementierungen zu ersetzen, die so funktionieren, wie man es sich vorstellt, und deren Verhalten ausreichend definiert ist
      Etwa indem man zentrale Datentypen, die Standardbibliothek usw. austauscht
      Besonders seit C++20 fühlt sich die Grundlage für solche Ersatzlösungen ziemlich nativ und ausdrucksstark an
      Viele neue C++-Projekte, die ich sehe, schlagen sehr stark diese Richtung ein
      Dass man leicht eine systemnahe domänenspezifische Sprache für Anwendungen bauen kann, ist eine Stärke von C++
    • Bei einem Ultima-ähnlichen Projekt, das ich mit C++/SDL2 gebaut habe, habe ich nur ein paar C++-Features verwendet
      Leider habe ich es nicht fertiggestellt, aber woran ich mich erinnere, sind Klassen, std::function, std::unordered_map, std::string und std::unique_ptr
      Ich kann mir kaum vorstellen, fremden Code zu lesen, wenn er nicht in einem ähnlichen Stil geschrieben ist
      Da ich beruflich keine großen Programme schreibe, war das Schwierigste, über Programmiermuster wie das Visitor-Pattern hinauszukommen
      Ich wünschte, C++ wäre bei C++11 stehen geblieben
      Das Komitee scheint inzwischen alles in die Sprache aufnehmen zu wollen, und C++ wirkt wie eine gigantische Sprache, die jeden Nischen-Programmierstil unterstützt
    • C++ ist ein komplettes Chaos
      Aber ein unterhaltsames Chaos, und ich schreibe gern in C++
      Manchmal ist das wichtig
      Mein Verhältnis zu Rust ist deutlich kühler
      Ich respektiere Rust, nutze es, wenn ich denke, dass Rust richtig ist – besonders in Kontexten wie der Arbeit, in denen C++ schwer zu rechtfertigen ist –, und halte das, was Rust tut, für wichtig
      Aber obwohl ich inzwischen ziemlich viele Rust-Projekte gemacht habe, finde ich das Schreiben darin langweilig
      In zentralen Punkten ist es besser, aber zumindest für mich macht es weniger Spaß
    • Ist Rust nicht ebenfalls eine Sprache, die dieselbe Kontrolle und Low-Level-Nähe wie C bieten will?
      Wenn man das Siegel unsafe bricht, kann man Integers explizit in Pointer casten und zum Beispiel Hardware über Memory-Mapped I/O steuern, oder nicht?

  • Dieser Artikel ist eine lange, weit ausholende Tirade, und schon die Buchstaben „C++“ können Leute so triggern, dass vieles ignoriert wird
    Mir geht es manchmal auch so
    Für die Beschwerden kann man zum Abschnitt „It's Not All Puppies and Butterflies“ springen
    Der Autor war von C++11 stark beeindruckt, und nachdem ich C++ fast 20 Jahre lang absichtlich ignoriert hatte, ging es mir ähnlich
    Es ist schön, dass Pakete und Bibliotheken vorgestellt werden, mit denen man herumspielen kann, aber eine weitere Bibliothek in mein Projekt einzubauen ist immer noch oft schmerzhaft
    Single-File-Header kommen mir in den Sinn
    FTXUI ist interessant
    Und cppreference.com ist wirklich großartig
    Die Python-Dokumentation ist auch ziemlich gut, aber ich habe noch keine Dokumentation gesehen, die so gut ist wie cppreference.com

    • cppreference.com ist, wie der Name sagt, als Referenzdokumentation hervorragend
      Die Python-Dokumentation ist über verschiedene Stellen verteilt, an vielen Stellen unvollständig und ihr fehlt ein einheitlicher redaktioneller Stil
      Nach dem Diataxis-Framework deckt sie aber nicht nur Referenzdokumentation, sondern mehrere Arten von Dokumentation recht gut ab
      Die Leute, die diese Dokumentation schreiben, berücksichtigen dieses Framework ausdrücklich und suchen nach Wegen zur Verbesserung
      Trotzdem ist es eine ehrenamtliche Open-Source-Arbeit, die sich fast genauso bewegt wie Codeentwicklung
    • Nachdem ich in Schule und Universität C++ gelernt hatte, bin ich beruflich sofort zu Python/JavaScript gewechselt; dieser Artikel hat viele C++-Lücken gefüllt, von denen ich gar nicht wusste, dass ich sie hatte
      Eine Zeit lang wollte ich „näher ans System“ heran, und Rust nebenbei zu lernen war auch nicht einfach
      Der Artikel gibt mir Hoffnung, dass es vielleicht möglich ist, C++ wieder aufzufrischen
      Hallo CMake … nein, vielleicht sollte ich wohl Meson sagen

  • Wenn ein talentiertes Team modernes C++ gut beherrscht und ein neues Projekt startet, stimme ich zu, dass C++ großartig ist
    Es ist eine angenehme und mächtige Sprache, performant, und obwohl sie komplex ist, sind Debugging und Optimierung vergleichsweise intuitiv
    Ich hatte Gelegenheit, an einer etwa fünf Jahre alten Codebase zu arbeiten, die nach C++11-Maßstäben geschrieben war, und aus vielen der im Artikel genannten Gründe war das sehr angenehm
    Eine alte Codebase, die sich über 20 bis 30 Jahre entwickelt hat, oder eine Codebase, die nicht von fähigen Leuten gepflegt wurde, wäre dagegen eine völlig andere Erfahrung

    • Ich habe mein Entwicklerleben mit PHP begonnen und mir beim Arbeiten beigebracht, maßgeschneiderte WordPress-Themes mit Plugins für spezielle Datentypen zu bauen
      Mit 21 bot mir die Firma an, mein Studium zu bezahlen, also kehrte ich für ein Informatikstudium zurück und wechselte später zu Computer Science
      Am ersten Tag des Kurses „Einführung in die Programmierung“, als ich C++ berührte, war ich sofort verliebt
      Im Vergleich zu PHP 7, das ich damals nutzte, waren Typsystem, Debugging und Ökosystem großartig
      Mit Erlaubnis meines Managers baute ich für Teile der bestehenden Intranet-Apps eine C++-basierte API, die PHP über WebSockets aufrief, und konnte so Typsystem und Performance nutzen
      Diese Systeme werden im gesamten Unternehmen bis heute täglich genutzt, und die Wartung war kein Problem
      Sogar obwohl sie in einer ziemlich ungewöhnlichen Umgebung namens IBM Pase for i laufen
      Heute, nachdem ich Rust und Axum ausprobiert habe, würde ich für solche APIs das Rust-Ökosystem deutlich bevorzugen, aber C++ verdient Anerkennung
      Besonders wenn man aus Web-Sprachen wie JavaScript ohne TypeScript oder PHP kommt, ist es eine wirklich großartige Sprache
    • Unter der Bedingung einer alten Codebase, die sich über 20 bis 30 Jahre entwickelt hat oder nicht von fähigen Leuten gepflegt wurde, fällt mir keine andere Sprache ein, die nicht schrecklich wäre
      Tatsächlich würde ich C++ wohl mehreren Alternativen vorziehen, die mir einfallen, etwa C, Java oder Fortran
      Die Ausnahme könnte C# sein, aber ich weiß nicht, ob es alt genug ist, um in diese Bedingung zu fallen

  • Entgegen der Behauptung, C++ habe inzwischen eingebaute reguläre Ausdrücke und sie seien ziemlich gut, kann man std::regex kaum als gut bezeichnen
    Wegen schlechter Performance und mangelhafter Unicode-Unterstützung sollte man es im Allgemeinen eher meiden

    • Auch der Linter, den wir in unserer Firma verwenden, erzwingt, std::regex nicht zu benutzen
    • Ich frage mich, ob es in der Spezifikation Probleme gibt, die zu Performance-Einbußen führen

  • Ich habe C++ gelernt und hatte auch Spaß daran, bin aber nie wirklich tief eingestiegen
    C hat mir immer besser gefallen, und es gibt viele erstklassige Codebases, die man lesen kann, um C besser zu lernen, etwa die ursprüngliche Dune-Game-Engine oder Unix-Utilities
    Nachdem ich mich kürzlich ein wenig mit Rust beschäftigt habe, sehe ich kaum noch einen starken Grund, C++ zu verwenden
    Die Kombination aus einem von funktionaler Programmierung inspirierten starken Typsystem und Performance scheint schwer zu schlagen und wirkt fast wie eine perfekte Sprache
    Trotzdem gibt es sicher Legacy-Gründe, aus denen man C++ verwenden muss
    Vielleicht Game-Engines, Embedded-Programmierung oder andere Arten von Legacy-Bindungen

    • Ich wechsle beruflich zwischen C++ und Rust, und ehrlich gesagt werden in modernem C++20/23 viele Schmerzpunkte behoben, indem man Rust nahezu kopiert
      Eine neue C++-Codebase kann man durchaus ziemlich sauber aufsetzen
      Aber ich verstehe zu diesem Zeitpunkt nicht wirklich, warum man neue Software in C++ schreiben sollte
      C++ hat viele lästige Seiten
      Library-/Paketmanagement ist nicht standardisiert, Header sind Code-Duplikation, und die Standardbibliothek hängt von der Implementierung ab und ist kaum lesbar
      Der Standard enthält merkwürdiges Verhalten, Leute verlassen sich auf undefiniertes Verhalten, ohne es zu merken, es gibt Use-before-allocation-Probleme, und durch Ownership-Probleme sowie falsche Reference Counts entstehen subtil Memory Leaks
      Man muss alles mit const versehen, statt es zum Default zu machen, für noexcept muss man die Exceptions von allem prüfen, was man aufruft, und Fehler in Standardbibliotheksoperationen sind schwer lesbar
      Stark objektorientierter Code ist praktisch technische Schuld
      Der LSP von C++ arbeitet nicht strukturell wie bei Rust, wo der abstrakte Syntaxbaum geprüft wird, um Definitionen zu finden; dadurch sind Navigation und das Verstehen einer Codebase langsamer
      Rust unterstützt nostd ausdrücklich als First-Class-Funktion, während man in C++ compiler-spezifische Flags braucht, um die Standardbibliothek abzuschalten, und schwer prüfen kann, ob man es richtig gemacht hat
      Deshalb überzeugt mich das Argument, man verwende C++ wegen Embedded, nur wenig
      In Rust gibt es ebenfalls Game-Engines wie bevy, auch wenn sie noch jung sind, und wenn man möchte, kann man Rust an Godot-Scripting anbinden
      Low-Level-Audio ist in Rust genauso einfach, und Cross-Platform-Handling ist mit einer einzigen Crate möglich
      Insgesamt sehe ich Legacy-Code und die Zurückhaltung gegenüber Veränderung als Kern des Problems
    • Legacy ist nicht nur bei in C++ geschriebenen Apps enorm, sondern auf vielen Ebenen
      Dazu gehören die Zahl der Nutzer, veröffentlichtes und verfügbares Wissen und Material, Bücher, Kurse, Blogs, Artikel, Videos, Softwarebibliotheken sowie die hohe Kompatibilität mit C, einer weiteren riesigen Sprache
      Für jemanden, der länger als ein paar Jahre in diesem Bereich ist, ist das beinahe Allgemeinwissen der Softwarebranche
      Ich habe C++ nie besonders viel verwendet und bin daher kaum ein richtiger Anfänger darin, aber früher habe ich klassische C++-Bücher vom Sprachschöpfer Bjarne Stroustrup, von Scott Meyers und anderen gekauft, gelesen und einigermaßen verstanden
      C dagegen habe ich über Jahre hinweg viel in der Produktion eingesetzt, einschließlich erfolgreicher kommerzieller Produkte
      https://www.stroustrup.com/applications.html
      https://www.stroustrup.com
      https://en.m.wikipedia.org/wiki/Bjarne_Stroustrup
      https://en.m.wikipedia.org/wiki/Scott_Meyers
    • C++ ergibt Sinn, wenn man niedrige Latenz braucht, sich aber nicht besonders um Korrektheit kümmert
      Deshalb glaube ich, dass die Spieleentwicklung am längsten bei C++ bleiben wird
      Wenn bei 0,001 % der Nutzer das Spiel wegen eines Segmentation Fault abstürzt, heißt es im Grunde: na und?
    • High-Frequency Trading wäre ebenfalls eine Möglichkeit