Die zwei Lager von C++

 (herecomesthemoon.net)
10 Punkte von GN⁺ 2024-11-26 | 3 Kommentare | Auf WhatsApp teilen
  • Der Traum von einem einzigen C++ ohne Dialekte scheint schon vor langer Zeit verschwunden zu sein
  • Auf Reddit, der orangefarbenen Website (HN) und in den offiziellen Sitzungen des C++-Standardkomitees gibt es viele Debatten über die Zukunft von C++

Der aktuelle Zustand von C++

  • Die Evolution Working Group (EWG) von C++ hat sich darauf geeinigt, P3466 R0 anzunehmen.
    • Beibehaltung der Link-Kompatibilität mit C und älterem C++ ohne ABI-Bruch (Application Binary Interface).
    • Keine Verwendung von „viralen Annotationen“.
    • Festhalten an den widersprüchlichen Zielen von ABI-Stabilität und dem Zero-Overhead-Prinzip.
  • Die US-Regierung empfiehlt, die Verwendung von C++ einzustellen.
    • Mehrere Behörden wie CISA, NSA und das Weiße Haus haben Warnungen vor der Nutzung speicherunsicherer Sprachen veröffentlicht.
  • Große Technologieunternehmen führen Rust ein.
    • Microsoft, Google und AWS nutzen Rust.
    • Google entwickelt sogar Tools für die Interoperabilität zwischen C++ und Rust
  • Interne Konflikte innerhalb der C++-Community
    • Es gibt Berichte, dass Herb Sutter Microsoft verlassen hat und MSVC bei der Implementierung von C++23-Features langsam vorankommt.
    • Google reduziert seine Beteiligung am C++-Entwicklungsprozess und entwickelt eine eigene Nachfolgesprache für C++.
    • Mangelndes Vertrauen in den bestehenden Prozess des C++-Standardkomitees
    • Die Modul-Funktionalität ist noch immer unvollständig
    • „Safety Profiles“ befinden sich in einem merkwürdigen Zustand

Die zwei Kulturen von C++

  • Die moderne Gruppe mit automatisierten Tools
    • Große Technologieunternehmen wie Google sind die wichtigsten Beispiele
    • Nutzung aktueller C++-Standards (C++17 und neuer) mit Unterstützung durch automatisierte Build- und Test-Tools
    • Investitionen in die Sicherung der Codequalität und die kontinuierliche Modernisierung der Codebasis
  • Die Legacy-C++-Gruppe
    • Codebasen, die in alten Umgebungen und mit alten Tools betrieben werden
    • Betrieb ohne Quellcode oder mit veralteten Build-Systemen
    • Hohe Wartungskosten und große Hürden für die Modernisierung
  • Der wichtigste Unterschied liegt bei Tools und Prozessen
    • Die moderne C++-Gruppe verlässt sich auf integrierte Build-Systeme sowie Tools wie statische Analyzer, Formatter und Linter
    • Der Legacy-Gruppe fehlt es an solchen Tools und Prozessen, was die Betriebseffizienz senkt

Ergebnisse und Auswirkungen

  • Safety Profiles
    • Ziel ist es, die Sicherheit zu erhöhen, ohne bestehenden Legacy-Code verändern zu müssen
    • Der Fokus liegt eher auf der Pflege vorhandenen Codes als auf den Anforderungen modernen C++
  • Module
    • So konzipiert, dass Header-Dateien einfach als Module importiert werden können
    • Entworfen unter Berücksichtigung der Kompatibilität mit Legacy-Code
  • Spaltung der C++-Community
    • Die unterschiedlichen Anforderungen der modernen und der Legacy-Gruppe verschärfen die Konflikte innerhalb der Community
    • Der konservative Ansatz des C++-Standardkomitees wirkt wie ein Versuch, diese Konflikte abzumildern

Eine alternative Perspektive

  • Alternative Ideen wie Safe C++ werden innerhalb der Community nicht begrüßt
  • Es gibt Kritik, dass einige Mitglieder des Standardkomitees an persönlichen ästhetischen Maßstäben festhalten und sich gegen Veränderungen sperren

Verwandte Beiträge

3 Kommentare

 
aer0700 2024-11-27

Rust hat noch kein GUI-Entwicklungsökosystem, deshalb wird es bisher nicht übernommen.
Es müsste ein brauchbares GUI-Framework für Rust herauskommen...
 
ndrgrd 2024-11-26

Ob Rust C++ ersetzen kann, weiß ich nicht genau,
aber dass man kaum noch neue C++-Projekte sieht, stimmt schon …
Das C++-Komitee scheint entschieden zu haben, dass es richtiger ist, die ursprünglichen Werte höher zu gewichten als eine Metamorphose.
 
GN⁺ 2024-11-26
Hacker-News-Kommentare

  • Googles C++-Code funktioniert oft nicht mit neueren Versionen, und Entwickler sind häufig nicht bereit, das zu beheben. Der Grund sei, dass Googles Code zwischen alt und modern in einer Art Zwischenzustand feststecke

    • Googles C++-Code könne durch Zustandsmaschinen und manuell verwaltete schwache Pointer zu Speicherbeschädigungen führen
    • Es werde positiv gesehen, dass Google das C++-Ökosystem verlässt
    • Es wird angenommen, dass Googles Interesse am Rust-Ökosystem nichts Gutes bedeuten wird

  • Den C++-Standardisierungsverantwortlichen wird geraten, die aktuelle Richtung von C++ weiter zu unterstützen und das Online-Rauschen über die Zukunft von C++ zu ignorieren

    • Wer statische Lifetime-Prüfungen wolle, solle Rust verwenden
    • Wer für Regierungsauftragnehmer arbeite, solle Rust verwenden
    • Es wird behauptet, dass der bestehende C++-Entwicklungsprozess gut funktioniere

  • Es wird behauptet, dass die einzigen Gruppen, die noch C++ verwenden, solche mit Legacy-Codebasen seien, die zu groß zum Refactoring sind

    • Andere Gruppen, die das Vertrauen in WG21 verloren haben, wechseln zu neuen Sprachen
    • Es wird erwähnt, dass Herb Sutter gesagt habe, das Hinzufügen von Lifetime-Annotationen zu C++ würde eine "Ausfahrtsrampe" in andere Sprachen schaffen

  • Das Edition-System von Rust wird als sehr gut funktionierend bewertet

    • Es wird vorgeschlagen, dass ein solches System auch in C++ eingeführt werden könnte; trotz möglicher Einschränkungen an Modulgrenzen wäre das vielleicht ein Weg, beide Lager zufriedenzustellen

  • Es besteht Sorge, dass die Nachricht von Herb Sutters Abschied von Microsoft negative Auswirkungen auf Microsoft haben könnte

    • Herb habe die Einführung des C++-Standards vorangetrieben und sich um eine bessere Zukunftsvision bemüht
    • Es wird erwähnt, dass std::span, ein Vorschlag von Microsoft, ohne Bounds-Checking übernommen wurde, und es wird behauptet, dass Herbs Einsatz nötig gewesen sei

  • Es wird betont, dass automatisierte Tests der wichtigste Faktor zur Unterscheidung der beiden Lager seien

    • Bei Legacy-C++-Apps ohne automatisierte Tests bestehe bei Codeänderungen das Risiko, die Anwendung zu beschädigen
    • Es wird gewarnt, dass aufgrund der Eigenschaften von C++ selbst harmlos wirkende Codeänderungen Probleme verursachen können

  • Es wird behauptet, dass das Fehlen von Modulen ein Hauptgrund dafür sei, dass C++ an Attraktivität verloren habe

    • Mit Modulen hätte sich möglicherweise eine C++-Community herausbilden können

  • Herb Sutter sei gut darin gewesen, Kompromisse herbeizuführen, während Google im Vergleich dazu seine eigene Agenda durchgedrückt habe

  • Es wird erwähnt, dass Kunden mit großen Codebasen nicht einmal 1 % ihres Codes ändern wollten, nur um strenge Regeln zu erfüllen

    • Es wird behauptet, dass viele Unternehmen Zeit in Upgrades auf neue Standards investieren

  • Es wird erklärt, dass es auch bei Python und Javascript/Node/Typescript mehrere Lager gibt

    • Rust habe versucht, solche Lager zu vermeiden, dafür sei die Lernkurve aber steiler geworden
    • Go habe versucht, Lagerbildung zu verhindern und breite Akzeptanz zu erreichen, habe dann aber Generics einführen müssen