In Chromium verbotene C++-Funktionen

 (chromium.googlesource.com)
15 Punkte von GN⁺ 2026-01-26 | 3 Kommentare | Auf WhatsApp teilen
  • Das Chromium-Projekt definiert den Einsatzbereich und die verbotenen Elemente moderner C++-Standardfunktionen klar, um Code-Konsistenz und Sicherheit zu gewährleisten
  • Für C++11 bis C++23 wird pro Standard zwischen erlaubt, verboten und in Prüfung (TBD) unterschieden; für die Abseil-Bibliothek gelten dieselben Kriterien
  • Zu den verbotenen Funktionen gehören std::shared_ptr, std::function, std::regex, std::filesystem, std::byte, char8_t, modules
  • Erlaubte Funktionen sind unter anderem concepts, der Spaceship-Operator, designated initializer, std::to_underlying, std::ranges-Algorithmen
  • Dieser Leitfaden gilt für Chromium und alle Unterprojekte und dient als zentraler Maßstab zur Sicherstellung von Code-Stabilität und Build-Kompatibilität

Richtlinie für den Einsatz von Modern C++ in Chromium

  • Chromium übernimmt neue C++-Standards nicht sofort, sondern markiert sie erst dann als anfänglich unterstützt (initially supported), wenn die Toolchain-Unterstützung ausreichend gesichert ist
    • Danach werden einzelne Funktionen als erlaubt (allowed), verboten (banned) oder in Prüfung (TBD) eingestuft
  • Änderungen am Status neuer Funktionen können über die Mailingliste cxx@chromium.org vorgeschlagen werden
  • Zwei Jahre nach der anfänglichen Unterstützung werden Funktionen nach ausdrücklicher Prüfung in die Liste der erlaubten oder verbotenen Elemente verschoben

Verbotene Funktionen in C++11

  • Sprachfunktionen: inline namespace, long long, benutzerdefinierte Literale (user-defined literals)
  • Bibliotheksfunktionen: , , -Engines, , , usw.
    • Ausnahmen (exceptions) sind vollständig deaktiviert; nur noexcept ist erlaubt
    • Anstelle von std::bind, std::function, std::shared_ptr, std::weak_ptr werden base::Bind, base::Callback, base::RefCounted verwendet

Verbotene Funktionen in C++17

  • UTF-8-Zeichenliterale (u8) sind verboten, wegen Kompatibilitätsproblemen mit char8_t
  • Verbotene Bibliothekselemente:
    • mathematische Spezialfunktionen, parallele Algorithmen (parallel algorithms), std::any, std::byte, std::filesystem, std::pmr-Speicherressourcen usw.
    • Parallele Algorithmen sind wegen fehlender Unterstützung in libc++ und möglicher Konflikte mit dem Threading-Modell von Chrome verboten

Erlaubte und verbotene Funktionen in C++20

  • Erlaubte Sprachfunktionen:
    • concepts, consteval, designated initializers, der Spaceship-Operator, [[likely]], Initialisierung in range-for-Anweisungen
  • Erlaubte Bibliotheksfunktionen:
    • , , , , std::erase_if, std::ranges::subrange, std::to_underlying usw.
  • Verbotene Funktionen:
    • char8_t, modules, [[no_unique_address]], std::bit_cast, ``, std::bind_front, std::ranges::view_interface
  • In Prüfung (TBD): coroutine, , , std::u8string

Erlaubte und in Prüfung befindliche Funktionen in C++23

  • Erlaubte Sprachfunktionen: #elifdef, if consteval, statischer Operator (static operator)
  • Erlaubte Bibliotheksfunktionen: std::byteswap, std::basic_string::contains, std::to_underlying, erweiterte std::ranges-Algorithmen
  • In Prüfung befindliche Funktionen: std::expected, std::mdspan, std::generator, std::stacktrace, std::print, [[assume]], #warning usw.

Richtlinie für die Abseil-Bibliothek

  • Verbotene Abseil-Komponenten:
    • absl::any, absl::optional, absl::StatusOr, absl::Span, absl::FunctionRef, absl::Mutex, absl::Time, absl::btree_* usw.
    • Die meisten davon werden durch Implementierungen im base-Namespace von Chromium ersetzt (base::span, base::expected, base::Bind usw.)
  • In Prüfung (TBD): absl::linked_hash_set, absl::linked_hash_map

Gesamtbedeutung

  • Chromium übernimmt Standard-C++-Funktionen nicht pauschal, sondern wählt sie anhand von Build-Stabilität, Sicherheit, Performance und Code-Konsistenz aus
  • Die meisten verbotenen Funktionen sind entweder auf doppelte Implementierungen (base::) oder auf Probleme mit Toolchain- bzw. ABI-Kompatibilität zurückzuführen
  • Dieser Leitfaden fungiert als Qualitätsmaßstab für C++-Code im Chromium-Ökosystem und ist bei der Open-Source-Zusammenarbeit ein unverzichtbares Referenzdokument

Verwandte Beiträge

3 Kommentare

 
karikera 2026-01-27

Schade, dass C++ aus Gründen der Abwärtskompatibilität immer weiter aufgebläht wird..
 
tsboard 2026-01-26

Wirklich eine riesige Sprache, wie es in den HN-Meinungen heißt: C++ ...
 
GN⁺ 2026-01-26
Hacker-News-Kommentare

  • Nichts sticht besonders hervor, aber im Kern heißt es meistens: „Lasst uns intern entwickelte Bibliotheken verwenden, die zu unserem Einsatz passen.“
    Der Rest wirkt weitgehend vernünftig, etwa das Vermeiden von Locale-Problemen. Es gibt auch Optionen, um die rauen Kanten der Standardbibliothek zu glätten, daher ist das nachvollziehbar.

    • So etwas sieht man oft in Unternehmen mit alten Codebases. Früher gab es noch kein chrono, also hat man eigene Zeit-Typen gebaut, und man nutzte eigene Container schon bevor sich die STL stabilisiert hatte.
      Wenn man heute ein neues Projekt starten würde, wären die meisten dieser Regeln vermutlich bedeutungslos.
    • Interessant ist, warum char8_t verboten ist. Es gibt kaum noch Encodings außer UTF-8, und char8_t* ist nicht kompatibel mit char*, daher wird empfohlen, std::string oder std::string_view zu verwenden, um eine Flut von Casts zu vermeiden.
    • Als jemand, der diese Seite über mehr als 10 Jahre gepflegt hat, finde ich es bemerkenswert, dass dieses Dokument am selben Tag gleichzeitig bei r/c++ und auf HN auftauchte. Es gibt nichts wirklich Neues darin, daher frage ich mich, warum es plötzlich zum Thema wurde.
    • Manche Punkte sind nicht bloß Trägheit, sondern liegen daran, dass Googles Implementierung eine in manchen Aspekten streng genommen bessere Architektur als der Standard hat. Die Standardtypen hätten besser entworfen sein können.
    • Es gibt die Wahrnehmung, dass Google intern von fast jeder Technologie eine eigene Version hat. Das Problem ist, dass manche das blind nachahmen und dabei den Kontext verlieren. Ein typisches Beispiel ist die Einführung von Kubernetes in einer Organisation mit 20 Entwicklern und 50 Services.

  • Die Rede über alten Code erinnert mich daran, als Chromium zum ersten Mal erschien.
    Es ist schon erstaunlich, dass diese Codebase bereits vor 20 Jahren begonnen wurde.

  • Dass <regex> verboten ist, war eine gute Entscheidung. Es konnte UTF-8 nicht richtig verarbeiten und war deshalb praktisch unbrauchbar. Erstaunlich, dass so ein fehlerhaftes Design standardisiert wurde.

    • Heutzutage unterstützen die meisten Regex-Bibliotheken einen Unicode-Modus. Regex ist als Technik selbst älter als UTF-8.

  • Im übergeordneten Verzeichnis gibt es noch interessantere Dokumente.
    Der Chromium C++ Style Guide ist lesenswert.

  • Exceptions sind verboten, aber Windows ist die einzige Ausnahme.

    • Googles Code basiert ursprünglich stark auf C-Stil und ist daher nicht exception-sicher. Wenn man heute neu anfangen würde, wäre es besser, Exceptions zu nutzen, aber wegen der Kompatibilität mit bestehendem Code ist das schwierig.
      Sie wurden also nicht aus philosophischen Gründen verboten, sondern aus praktischen Gründen. Es heißt, dass man es anders gemacht hätte, wenn man ganz von vorn begonnen hätte.
    • Dieses Dokument ist nicht der Google Style Guide, sondern das Dokument zu modernen C++-Features in Chromium. Es behandelt weder Exceptions noch plattformspezifische Inhalte.
    • Ich habe nach „exception“ und „Windows“ gesucht, aber nur eine Erwähnung im Zusammenhang mit [[no_unique_address]] gefunden; vermutlich habe ich also einen Witz übersehen.

  • Die Liste verbotener Features ist so lang, dass sie größer wirkt als der gesamte Funktionsumfang von C. Überwältigend.

    • C++ ist wirklich eine riesige Sprache.

  • Das Verbot von u8"..."-Literalen ist eine gute Entscheidung. Wenn der Quellcode selbst in UTF-8 geschrieben ist, braucht man keinen separaten Präfix.
    Solche Literale sind ein Fall, bei dem die Lösung vor dem Problem kam.

  • Ich würde gern wissen, welche Alternativen es für die verbotenen Features gibt. Bei <filesystem> heißt es zum Beispiel, die Testunterstützung sei unzureichend und es gebe Sicherheitsprobleme.

    • Bei den meisten verbotenen Einträgen steht die Ersatzbibliothek direkt daneben. <filesystem> ist die Ausnahme.
    • Vermutlich gibt es in der Chromium-Entwicklerdokumentation dazu Informationen.
    • Üblicherweise verwendet man base/files.

  • Modules sind verboten. Man hätte stattdessen vielleicht einfach das Modulsystem der Sprache D kopieren sollen.

    • Der Grund ist wohl die mangelnde Compiler-Unterstützung.

  • Die Verbotsliste zeigt, dass bei solchen Dingen der Kontext wichtiger ist als moderne Features. In kleinen Apps ist das unproblematisch, in großen Projekten wird es riskant.

    • Der Kern von Googles Richtlinien ist, dass auch Leute ohne Sprachspezialisierung sicher beitragen können. Das Ziel ist also weniger die Projektgröße als organisatorische Konsistenz.
      Berücksichtigt wird auch die Portabilität über verschiedene Plattformen hinweg.
    • Oft behält man eigene Implementierungen aus historischen Gründen oder wegen Kompatibilität bei. Viele dieser Funktionen existierten schon vor der Standardisierung und lassen sich daher nur schwer austauschen.
    • Ich finde ebenfalls, dass es für Leser weniger belastend ist, Konsistenz zu wahren, statt überall neue Features einzustreuen und Regeln zu vermischen.